I don't really understand this take. Appkit/Uikit _is_ the dependency.

It's not a third party dependency.

This is also my favourite thing about the Apple platform. My apps usually do not have any dependencies and when they have they are often my own. It keeps it simple.

I've built my note-taking app[1] in Qt, and while I worked hard to make it look good, I'm very satisfied with the result.

Also, it turns out to be much faster than comparable native apps (performance benchmarks available on the website).

[1] https://www.get-plume.com/

Looks really nice. Just a heads-up, I get a NS_BINDING_ABORTED error on the home page video, so I can't see it. (Firefox 121.0, Linux).

Whoops. I'll look into that, thanks!

Looks good indeed. Well done.

No BBedit in the comparison list?

BBedit is awesome but it's not a block editor. Can it render a complex Kanban within the same document? Can it do drag and drop? No.

I do see you have block editing in the qualifying statement for your speed comparison list, but Kanban seems to only be in your upcoming features list? I use bear regularly, but none of the features you mention are why I use bear; it's just a nice markdown editing experience and I'm rarely, if ever, dragging and dropping blocks within a document. I suppose if there are enough people who do find that crucial, you might want to emphasise it a little more, I don't think I spotted any mention of it.

I didn't mention it since I'm yet to implement it. I think I'll release Plume's beta in around two months, so I've got plenty of time to work on those. And yes, the Kanban is work in progress, but I'm nearly done[1].

[1] https://imgur.com/NIgDLOU

Hmm, maybe that does look kind of interesting, thanks for the pic. Have you thought of any alternative ways to represent the todo checkbox in those Kanban tiles? Maybe aligning to the top instead of vertical center?

I haven't thought about that. In the regular editor, the checkbox is aligned to the top of the text. I'll experiment and see how it goes. Thanks for the suggestion.

You have one of the few Qt-based apps that looks and feels like it belongs on macOS. Really well done.

Thank you!

Looks great! Did you use QT Quick or the Widgets?

Must be Widgets since using QML at work makes me regularly wanna rip my hair out. Its one of the worst frameworks Ive used once you go beyond simple hello world programs.

Nope. See my comment above - I've used QML. I've built a very complex block editor with it. What problems are you facing?

I did use Qt Quick and I've been having such a great experience (as someone that used to program GUI imperatively via Qt C++ or using other framework like React/React Native) in my opinion, Qt C++ and Qt Quick is the best combo for a GUI framework. You get the performance of C++ and the simplicity, fluid animations, reactivity of QML, etc... My block editor is build in such a way that the models are in C++ and the views are in QML. This separation of logic and presentation works really well. I'll probably wrote a blog post about it.

And you are now locked down to one environment.

If you’re an indie dev, that can be a good thing. I find it much simpler to ship for iOS and Mac as a solo dev.

Yes, initially it is easier, but it is more difficult to scale to other platforms later on. It's all dependent on how much work you want to do upfront versus in the future.

As an indie dev, I feel like the greater risk is that you aren't able to release an MVP and find PMF at all, so I'd always err on getting something working on fewer platforms first so you can move quickly. Having the option to go multi-platform later is a good problem to have, but isn't guaranteed, so don't tackle it early on.

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.

Yep that's true, but it's still another reason I'd use Flutter or React Native simply because they make building for even one platform much easier than Swift, in my experience. Then you can build up afterwards because they also make building for other platforms easier too. It's just one reason why Electron for example is well used in companies.

“Easier” depends a lot on the project in my experience. For example if you need a tableview/datagrid as performant and feature rich as NSTableView on Swift/AppKit, you’re probably going to have to build it yourself with React (of any flavor) and especially Flutter (which has a heavy mobile bent to it) or at minimum settle for a community library that’s got big holes in its functionality.

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.

I think it depends on what you are building and who are your competitors.

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.

And? There are plenty of companies which have fared just fine under such "limitations".

The insistence that every application/framework must be cross-platform, or its worthless, is so bizarre to me. What is even the point of having multiple operating systems if they can't have distinct features to gain competitive advantage by attracting application developers? If operating systems can't differentiate, we might as well all use Windows.

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.

This could be at least partially solved if cross platform frameworks filled in feature gaps between platforms, making their feature set a union of features on all supported operating systems, but this rarely happens. Instead they typically take a least common denominator approach, limiting apps written with them to only the most common basic features.

“ feature gaps between platforms, making their feature set a union of features”

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.

It does happen though - Qt tries very hard to do that. I don't know about literally everything, but the majority of platform-specific features/optimizations can be exposed through Qt with enough work.

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.

Qt is probably closest among cross platform frameworks, but comes with some thorns that can be difficult to ignore and contribute to that “hard to use” sentiment.

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

You can use Rust with QML[1].

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

[2] https://www.get-plume.com/

[3] https://www.appflowy.io/

[4] https://github.com/stdware/qwindowkit

You have no idea how valuable and helpful this comment was to me. Thank you very much!

I'm glad!

> The way Qt Widgets is for practical purposes usable only with C++ or Python is one such thorn

What happened with using the best tool for the job?

So what if C++ and Python are the only bindings.

I'd like to take the opportunity to mention Slint: a new toolkit in the scene, is inspired by the spirit of Qt while aiming to address its shortcomings https://slint.dev

I've spent (what I thought was) quite a bit of time researching so many of these alternatives posted on this thread and this is the first I hear of slint, so thank you for sharing. It may be just what I was looking for

You talk as if Qt was really bad. Do you know of any toolkit that is better? I mean: Electron is a memory hog by default, Flutter or React I do not see they are available in those many languages you demand from Qt.

Which is that platonic toolkit I do not know of that is easy to distribute, productive, fast and available in any language?

For cross platform, from a technical standpoint Qt is one of best and that’s the problem. The best isn’t good enough, not for the masses that instead chose Electron and certainly not for the sorts of devs making polished Apple platform apps.

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.

The Telegram Desktop app is written with Qt, and I think they've done a pretty good job. I think there's a certain bias here. Most of the popular Qt apps are either open source or Enterprise software, both don't care much about UX and aesthetics. What I'm trying to get at, is that with some effort Qt apps can be on the same level (or very close) to native apps. That's what I aspire with my Qt apps as well.

What I find bizarre is that this is often discussed without considering the specifics of the app.

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.

> 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

I beg to differ. Many industries (Graphic design, many engineering disciplines and game development) have a defacto platform for this exact reason

It is a matter of product: better to target more people better than fewer. Technology is usually secondary here.

One man’s downside is another’s upside.

Indeed. Supporting a single platform means generally fewer bugs and headaches, as multi-platform is going to introduce new troubles regardless of how one goes about it. Approaches that try to be write-once-run-everywhere “silver bullets” will still see platform—specific bugs, as will per-platform codebases.

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.

Often worth it for superior UX.

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.

You can write app that will work on Windows, Mac, Linux, iOS, Android using Delphi.

Working is easy, working well isn’t.

The Windows 7 example on their home page does not inspire confidence. I'd much rather be locked into macOS than be locked into this

I brought it just as an example of what is possible. I do not give rat's ass whether it "inspires one's confidence" and who wants to be locked into what.

Freepascal is only tool I have found that creates same look and feel across platforms. After so many years of promise and intentions the cross platform issue only solved by Delphi/fpc to a professional level as far as I can tell. It's a metaphor for our industry chasing bling over productivity and generations seeking g rip and replace rather than understanding the constraints the prev gen worked with. Im only 60 but have worked with assembler, Algol, COBOL, Delphi, pascal, Awk, c#, various BASICs from apple II to VB.net. Python and JavaScript for 2 decades. Now most excited about Mojo.

I'm not sure one is locked down. One can write the model and the controller in the style one likes and then they just bind to appkit/uikit for the Apple versions.

This could be done despite nobody I know working this way. This used to be normal when x-windows was thriving.

One environment with support on a vast plethora of devices and a long lifespan.

Indeed, Apple customers are quite a big market of course, but as an indie dev especially, there are more markets to bring your products and services to. That is why I use frameworks like Flutter which work everywhere, even if they are worse than Apple's developer platforms (and this is subjective even still). The upside is simply too great to lock myself to only one platform.

Definitely. It can take awhile to get the hang of some of Apple's frameworks, but they're generally very high quality. The best sign of this is you can ship components with them, forget about the details that went into building said component over months, and then come back and evolve them mostly painlessly.

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.