I think people become super lazy... "Ah, it's will ocupie a few hundreds of RAM, no problem, let's ship it."
They are companies with billions or even trillions shipping shit with Electron.
I’ve worked in Qt apps on and off through my career.
I do not want Qt apps any more than I want Electron apps.
The solution is native apps using native platform tools, or one of the mature cross-platform toolkits.
Qt feels too locked in to old decisions that were the right choice at the time, but desktops and mobile have changed so much that it always feels like a clash of old and new.
That native UI will be faster than Electron and most other retained UI toolkits and will be just as capable of creating whatever your subjective view of “modern UI” is.
Don't confuse UI and UX. You can make Qt have the right UI, you can't make it have the right UX.
Now we take it for granted, and Mac apps feel as good or bad as everywhere else.
The person who made a Qt app may be designing it based off of cross platform UX but maybe you should follow your own advice and not conflate things.
You can quite easilymake a native UI and UX with Qt. You can also make things feel very non native via AppKit too.
Your argument has very little to do with the toolkit and more to do with the developers choices of what UX they prefer to design.
I haven't seen what you describe, even if it's theoretically possible. I'd really love to be shown an example.
I'm not saying it can't happen, and in fact, if it existed I wouldn't have noticed (I mean, the point is that you think it's native, so I wouldn't have noticed..) but I can't think of an example and I would love to see one.
https://blog.landr.com/musescore-ultimate-gude/
Audacity’s new UI also looks not too far off from Logic
https://youtu.be/BTQymidLYIM?si=_zoMdjlhDNsp53zH
I’m not saying it’ll be perfect, there’s still the issue of being designed cross platform. But it’s a far cry from being a Windows 95 UI with an aqua skin.
One of the bigger issues is that they haven’t yet adopted the latest macOS 26/27 UI paradigms but the nice thing with Qt is that it’s really easy to wrap AppKit views into the mix as you need.
Ah, but that's the problem, macOS UI isn't skin deep. Behind the looks, there are behaviours like:
- supporting the system-wide default Cocoa menus and menu-modifying behaviours like changing the shortcuts via System Settings rather than some in-app settings window
- support the Services menu in every single right-click menu, the one that's populated by AppleScripts, Automator services, and Shortcuts provided by the system, installed apps, and the user
- heck, even without the Services menu, supporting system-wide speech, spell-checking, and translation built into every native Cocoa text field
- for those of us who like it, Siri AI suggestions in text fields
- supporting macOS' accessibility settings like Dynamic Type, Large Type, proper support for VoiceOver in all widgets, etc. which come automatically to Cocoa widgets but require extra effort that's never really seen in Qt apps on the Mac
- supporting transitioning between light and dark mode when the system setting changes and not leaving random artefacts behind after the change
There's way more than just these examples but this is the point: looking like macOS isn't enough. It's feeling like macOS that's the trick and Qt apps always stand out as just a little foreign.
So people who make apps with Qt don't design for the Mac interface because it's far too much hassle to build all of that stuff in, if they even know that they have to.
——————————
I'm not convinced by a comparison with the Pro apps, either. Those, on both sides, are custom-designed UI. Yes, Apple's Pro apps use the system toolkit but they aren't your typical Mac app; anything that looks like them has to go out of its way to look like them. It's not like Qt gives "Pro app" look for free.
(And even if it did, that still doesn't mean the app would get all those behaviours I talked about before)
But even in the first image of the Musescore interface, I spot something foreign to Mac: a toolbar with a drag handle. Mac apps don't have that. Mac apps have NSToolbar, where the items are customisable in a standard way that every app adopts.
- Yes Qt doesn’t get the default context menu items but it’s trivial to add them. Meanwhile you can also override them in AppKit to look non standard.
- The original response was about whether Qt can provide modern looking and native looking apps. You’ve now shifted your goalpost from modern looking to being exactly what AppKit or SwiftUI does.
- Qt by default has basic accessibility support on macOS the same way AppKit does. It’s not always perfect but it’s not as dire as you make it out to be.
- Qt6 also supports theme changes fine.
But again, none of this is the premise of the original argument I was replying to. Your argument is all over the place because you then also claim that AppKit can make non native looking UIs but we should just ignore those while disregarding that you can also trivially make Qt look macOS like.
The point isn’t that Qt apps will look and behave 100% identical, the point is you can make them do so. But cross platform apps will always be somewhat alien on any platform unless you’re actually designing for each platform.
That’s not really inherent to the UI framework that prevents it.
Where?
> It was originally whether it can feel native
Yes, and feeling native includes behaviours, not just looks.
> and it can.
Except it doesn't. Still waiting on a single example of a proper Mac-feeling app written with Qt, looks and behaviour included.
> It's trivial to add them
If you're comparing to using a native toolkit, 'trivial' should mean 'for free' given that Qt already presents the developer with the option to use the native toolkit.
There's nothing trivial about integrating a proper Cocoa-provided NSToolbar into a Qt app. It's downright impossible to make a QToolBar both look and behave like NSToolbar.
> The original response was about whether Qt can provide modern looking and native looking apps
Yes, and then I mentioned that looking like a native app isn't the end of the story. The conversation moved on but, contrary to the assertion that the goalposts shifted (it didn't, the goalpost was always about the better UX of native toolkits), all I did was add detail as to what desktop UI toolkits provide that Qt doesn't.
Even then, AppKit is as old as Mac OS X. Hardly native. And in all that time, Qt never caught up.
> It's not as dire as you make it out to be
No, it actually is. So much of it just straight up doesn't work, things that AppKit provides for free without any effort at all. One would expect the native styling to be able to help with it but it simply doesn't.
> You've now shifted your goalpost from modern looking to being exactly what AppKit or SwiftUI does
Actually, I'll quote myself: "I'm still waiting for a single Qt-based app on macOS that feels like a macOS app" — no emphasis added, I even italicised 'feels' in my first reply.
Feeling native is more than just looks. It's behaviours. I'm repeating myself because even GP mentioned "better UX", not "better UI". The experience includes how things work.
Your assertion was "You can make Qt look however you want. The point is that it will give you native UI by default" — it was actually you who decided the discussion was all about looks, not about experience.
> Qt by default has basic accessibility support on macOS thce same way AppKit does
Not a single Qt app on my system supports Large Text. Simply doesn't do anything when I hold Cmd and move my pointer over things.
> It's not always perfect
Agreed that no accessibility system ever is, particularly if developers don't test it, but…
> but it's not as dire as you make it out to be.
Spoken like somebody who doesn't rely on accessibility features. Not just use, rely.
> Qt6 also supports theme changes fine.
My computer would say no to that, with random bits of the UI not changing colour at all when I change the system light/dark mode.
It was such a problem that one of the most-used cross-platform apps written with Qt, OBS Studio, completely disabled the native theme for its theming inconsistencies.
> But none of this is the premise of the original argument I was replying to.
Okay, so that just means you're having a new discussion with me, then. Besides which, GP's premise to which you replied was "Qt feels too locked in to old decisions that were the right choice at the time".
I don't see that I'm contradicting that. With late-90s to early-2000s design decisions (like toolbars that tear off with drag handles, like Office 2001/2003 and Visual Studio) the cornerstone of what each widget is designed to do and how its appearance should be, how it should behave, and how these things interconnect with other aspects of the UI system, those "old decisions" really do get in the way of the "better UX" that GP described.
Like I said, Qt apps feel like they're wearing a Mac skin over the bones of a Windows 95 program (okay, maybe more like 2000 or XP, but that's still almost 30 years old). Mac OS X has been out and supported all the things I've talked about in Cocoa and Carbon for as long and yet Qt still remains a poor facsimile on the Mac all this time later.
The experience is just as GP said, a clash of old and new. Probably less noticeable on Windows and Linux but sticks out like a sore thumb.
I continue to await any suggestion of a proper native-like app written in Qt that looks AND behaves like a modern Mac app.
And look, I don't mean for this to be an argument. It's got the shape of one but I really do enjoy discussing this with you. I guess, at the end of the day, that the idea that something might look acceptable on a system is sufficient to say that its toolkit is up to the job is not one that leads to the best user experience.
Windows - Win32 (C API) or MFC (C++) or WinForms (C#) or WPF or ...? macOS - Cocoa/AppKit in ObjC or Swift/AppKit? Linux - Qt (C++) or Gtk 2 or Gtk 3 or Gtk 4?
I too had code that worked across 3 platforms with wxwidgets and a 3D game toolkit incorporated in opengl for visualisation, with most 2d controls being drawn using wxwidgets OnPaint handlers for custom controls rendered natively on that platform. I wrote this single-handedly, with another colleague handling the network code and firmware on the remote hardware devices.
Everything else is sheer laziness as far as I am concerned. There's even less excuse today with the rise of LLMs to do the majority of UI coding for you.
What seems to have changed is the size of the costs - LLMs are really good at this - such that you can now say “well, maybe the returns aren’t that big, in fact maybe they’re zero, but this is easy enough, so why not”
De minimus improvement has always suffered this problem - we’re all fairly sure it’s worth something. Maybe there’s even real perceptible value when you fix the whole basket. But making the case is hard.
Not if your promary UI is web.
And yet most Android apps today take 50-100MB bundle size for very simple GUIs and take up lots of RAM and lots of time to load or react to anything.
So maybe we'd be better off with everyone bundling Qt after all.