Contrast with a lot of the web frontend ecosystem, where stuff might go stale within a few months. And the overall pervasive feeling of jank that comes when you're building UIs. (Though, I presume this goes away once you internalize browser layout engines better.)
For my two Mac apps, I use very few third party deps. They're simply not needed! They serve small, discrete purposes and could be replaced by bespoke code at a moment's notice. This is how software should be built! We've just forgotten about this because the browser ships with so little in terms of UI components.
Also, it turns out to be much faster than comparable native apps (performance benchmarks available on the website).
EDIT: Fixed.
It’s not a coincidence that macOS/iOS has long had a disproportionally large quantity of high quality indieware. Capable framework + minimal headaches = polished apps that an individual or small group can sustainably support, even within less profitable niches and without VC funding.
Cross-platform applications have their place, but sometimes I like having features that I can get in one place and nowhere else. Let them both exist and quit griping about it.
And what is the result? Everyone complains that Qt is too hard to use, and so it has utterly lost the cross-platform war to Electron, and meanwhile the devs who want the platform-native functionality (like the OP of the article) use the OS-native toolchains instead.
There's no silver bullet here.
The way Qt Widgets is for practical purposes usable only with C++ or Python is one such thorn, as is its use of custom types like QString. Both increase friction significantly as many devs aren’t able to use their preferred language and can’t use the language primitives they’re familiar with. Qt Widgets apps also require a good deal extra elbowgrease to make feel good on all supported platforms due to oddities in widget layout and drawing, and to my knowledge use of newer features (like blurred “vibrant” (macOS) or “mica” (Windows) window backgrounds requires dropping down to native code.
For QML, devs are stuck with JavaScript (which while functional, isn’t everybody’s cup of tea) and face some of the same issues that web/electron devs do with needing to pull in third party frameworks (like MauiKit[0]) to have a usable widget set.
Distribution is a problem across the board in Qt with tooling being a less than great state. It’s a very common issue to see crashes in Qt apps as a result of some incantation being missing.
In short Qt has the right idea, but I believe it’s held back by many of its technical and design decisions. I’d like to see a project that’s like it, but built in a modern language with good C interop so high quality efficient bindings can be easily generated, and has a bigger focus on good DX.
[0]: https://mauikit.org
QML is actually pretty amazing. I've been building my block editor[2] view entirely in QML while the model is in C++. This separation of logic and presentation works great. And yes, there are some crashes sometimes (that I find quite easy to debug thanks to the built-in debugger), but take for example a similar app that's built with Rust and Dart[3], in my testing there were still memory leaks that caused my computer to hang. It's better to know you have a bug than for it to be hidden from you.
I agree with parent commenter, saying these cross-platform frameworks will end up supporting the least common denominator set of features. But I found with external open source libraries, the community is catching up very fast. For example, you want the awesome translucency macOS apps have for your Qt app? Here you go[4]. Many such cases. It's also pretty straightforward to add your own custom OS-dependent code, especially so, if someone already open sourced his approach. I recently wanted to move the traffic light buttons on macOS for my app, but couldn't figure the Objective-C code for that. I ended up looking at either Tauri or Electron source code and found my answer.
[1] https://github.com/woboq/qmetaobject-rs
What happened with using the best tool for the job?
So what if C++ and Python are the only bindings.
Which is that platonic toolkit I do not know of that is easy to distribute, productive, fast and available in any language?
Developer experience is extremely important but it’s consistently something that’s swept under the rug with Qt, much to its detriment. Devs at large would rather be limited to a single platform or make huge tradeoffs in efficiency than live with bad DX.
This fundamentally doesn’t work for UI/UX. You have to pick a paradigm and implementation details at some point and the high level UX design of Windows UI dejure and Mac are just different, in ways that cannot be factored out of a framework without leaky abstractions.
Your choices are: the Qt/Tk/Swing approach write once, a solid if dated UX that is themeable but not truly native anywhere, the web app (or its QML/Flutter/FX equiv), wxwidgets etal which sort of tried to be native everywhere last century and looks and works that way, or at least two parallel independent native UI implementations which is a gargantuan more effort.
Or go whole hog with FLTK or your own custom thing. a11y? WTF is that?
“ Instead they typically take a least common denominator approach, limiting apps written with them to only the most common basic features.”
I wouldn’t call wxwidgets basic, but it is a mess. It can’t be any other way. If it could someone would have made it in the last 30 years.
Just because you use Cocoa/AppKit rather than drawing on a canvas does not magically make your app feel like a Mac app.
Literally 100s of side projects have started down this path. People eventually learn you can’t abstract everything away, at least not the labor intensive part.
I agree that not every app must be cross-platform. Text editors are a good example. The economics may or may not be more difficult. Yes the audience is smaller but the cost may be lower as well and you may have a competitive edge over cross-platform apps.
The problem with starting a single platform app is that you have to decide very early on that you're not going to need any collaboration/sharing features (unless the app is built on top of some cross-platform protocol or file format) and that you're not going to serve multi-platform users any time soon. This is a big decision with far reaching consequences.
I think there's a risk for developers (and tech bloggers) to become so enamoured with the fine details of their platform of choice that they lose touch with the priorities of the user community.
I beg to differ. Many industries (Graphic design, many engineering disciplines and game development) have a defacto platform for this exact reason
Trying to build for multiple platforms is a lot of overhead, not to mention UI paradigms don't always map one-to-one. Even building for both Mac and iOS (versus just iOS, for instance), for me, can be challenging since there are enough to differences between the two platforms in terms of UX that I have to take extra care to nail both experiences faithfully.
There’s also the whole third party dependency mess referenced in an earlier post, which is unavoidable with both — anything more involved than “hello world” is going to have a mile long list due to how barebones the frameworks themselves are.
Many B2B apps are built as plain web apps that run in the web browser and connect to a backend (CRUD apps). That's because business customers care less about the presentation, and more about the value that the software might deliver. If it saves them time or money - they will buy it no matter what the UX is. And many of them even prefer a tab in the browser, since they do their work in the browser anyway.
With B2C users often expect a more polished experience. More often than not they pay for a nicer, more polished thing, rather than for something that solves a particular pain point. Of course, the app should be useful, but that's table stakes. The deciding factor often becomes the UX. Thus in B2C, the client technology plays a bigger role. Depending on how many competitors offer a native UX, the users might not even consider you if they see that the app is not lightning-fast or has some weird, custom UI that looks off.
React Native has some native UI elements, but then many other things such as the navigation stack are reimplemented from scratch which results in a UX that appears to be similar, yet may work in weird ways that differ from native behavior. Plus React Native is pretty slow in my experience, and like any cross-platform thing has a ton of other weird edge cases and annoyances.
I have not used Flutter, but from my understanding, they have reimplemented the whole UI stack from scratch, and draw everything on a low-level graphical canvas. This means that it is even less native than React Native. They emulate/copy the native UI, but it is not the same. Not to mention that they have to do a ton of work to keep up with the latest changes in Android and iOS. Feel free to correct me.
For B2B, React Native, Flutter, or even Web/Electron are perfectly fine. For some less competitive B2C categories as well. For super competitive ones native is almost always a requirement.
The promise of fantastic cross-platform apps still hasn't borne out. We've been promised this since Java, yet converged on shipping Chrome with a webapp.
This could be done despite nobody I know working this way. This used to be normal when x-windows was thriving.