It's not even the AI prose which is the problem (although I detest it too); it's the lack of respect for the reader. I've started employing 'AI;DR' - if someone wants my (limited) time then they should earn it by writing themselves.
Like this, but the problem with such immediate mode GUI apps is that they constantly burn 1-2% of CPU when the app is idle. A waste of compute and power.
I'm waiting for Phase 2[1]: especially "Algebraic data types & pattern matching". Current tagged union[2] use is pretty awkward/verbose and lacks exhaustiveness checking and typed error handling.
Extensible trait support seems like another big one if the ecosystem is going to significantly grow. Not having clearly defined traits in the language made larger projects composing many libraries in Julia difficult.
Indeed! I wrote my note-taking app with a block editor (like Notion) in Qt with QML for the UI and C++ for the logic and it's been an incredible experience![1]
I know people would dismiss this, but I'm going to try to make the case for Qt - I'm currently converting my note-taking app to mobile and it's going very well.
I heard this repeated many times. You can create closed-source Qt apps without paying any money. You cannot statically link, though; you must obey the LGPL license; that is all.
And yes, you cannot use commercial modules, but that is kinda expected.
Yes, Qt is mature and high-quality software. If you’re doing OSS, then Qt is truly a no brainer. The amount of C++ you have to write is truly minimal, and it’s not “raw” C++. There’s a lot of tooling and libraries. You can target web now too, and QML is legitimately good.
If KDE can develop a high performance stable desktop, you can design whatever.
I have been involved in two non-trivial Qt mobile apps. Never again.
I don't know what your experience is, and I mean no offence or anything, but the only people I have seen who were happy with Qt for mobile development were people who had never tried to do it with a modern language, like Kotlin.
With Compose Multiplatform and Kotlin Multiplatform, you can write a cross-platform app in a modern language, and that is far better than C++.
Fable was the only model that was able to detect a data corruption bug in my Qt C++ note-taking app[1] that all other tested models (gpt-5.5 xhigh, GLM-5.1, Kimi 2.7, DeepSeek V4 Pro) didn't find. I'll test on GLM-5.2 and Mimo v2.5 Pro soon.
I asked Fable on max to create a mathematical model to show that c (speed of light) is emergent from pregeometric physics.
It said: I can't, but it would be lazy to say that is is not a possibility.
With some back and forth it created a 5 step plan to narrow down if our universe has all the right properties for this to be true.
We evaluated the first four stages to be true, and it wrote the solver to find out if the fifth test running the full model passes, but that will take thousands of hours of compute.
It's SwiftUI that is at fault here[1][2], not native apps in general. I wrote my native app in Qt C++ and QML and showed that it is *significantly* faster and uses significantly less RAM than similar web apps[3]. So, no, web apps, in general, are slower and uses more resources than well-engineered native apps.
> It's SwiftUI that is at fault here, not native apps in general.
The article you cited is from 2022 and so is irrelevant, since SwiftUI's performance profile completely changed as of xOS 26.
Claims like "It's hard to build a performant SwiftUI app" get into skill-issue territory, but more importantly, the reality is there are only "SwiftUI-first apps". All non-trivial SwiftUI-first apps will also use UIKit/AppKit as needed, typically for capabilties that aren't yet available via SwiftUI.
iOS 26 is very late to have acceptable performance in the framework that Apple promotes as what you should use. It should have had good performance from the day it was introduced.
WebKit have had great performance for a very long time now.
Why would any startup dare to use tech that only now got fast? Why not go with the battle tested WebKit?
It is also much easier to develop and test html pages than Apple specific tech.
> Claims like "It's hard to build a performant SwiftUI app" get into skill-issue territory
I don't know why SwiftUI evangelists are still doing this in 2026. How many examples of SwiftUI's poor performance have to be demonstrated over the years? Even basic things like List continue to lag behind NSTableView in the most recent releases.
All I have is my own experience. In my current app, my views are 100% SwiftUI. One of them uses a SwiftUI List which typically has hundreds of thousands of items, each with title, subtitle, duration, cover art, etc. I expect it would still be butter-smooth at 1M items.
Was my initial naive implementation as performant? No. My point is that optimization still matters in SwiftUI, and that optimization looks quite a bit different in SwiftUI than it does in AppKit/UIKit.
If you've used UIKit to any large degree, how bad SwiftUI is, almost a decade later, continuously punches you in the face. About 20% more time to write initially, for 90% less bugs and potholes, and I've tested this with iOS devs who never used UIKit before too. Now with AI, there is even less of an excuse IMO.
Leave SwiftUI to the settings pages. The gulf between AppKit and SwiftUI in macos desktop I'm not as sure about.
Can you point to a single performant, high-quality SwiftUI-first app with a messages-like chronological transcript and correct scrolling behavior on macOS? The problems with AppKit integration are real and should not be dismissed out of hand.
They even used the distinction “native-like” in the block editor article - which is really good, by the way and explains this distinction in more depth - but edited their comment now and that article is the third link and its anchored to the performance section so you won’t see that unless you scroll to the top.
Their point is more that SwiftUI has generally poor performance. Lots of native Windows frameworks have poor performance as well.
Native UI development is a minefield. If you want to build an app today that will still run in 20 years without a complete rewrite in the UI layer you should probably use wxWidgets if you are committed to native - even if only targeting one OS. But that model is really only appropriate for building traditional desktop apps. I don’t think the market would accept a Slack or Notion built that way today.
At this point on Win32 Qt might as well be the native UI. They did a better job of maintaining a coherent visual theme that says "Windows" and fits the design patterns than the actual owners of the platform.
I'd be more curious about that specific app. Niche bespoke commercial apps have this habit of being permanently stuck on old versions of Qt that don't handle these things as well as the newer versions. And until they are totally broken on Windows, the developers will never be motivated to lift a finger to fix this.
I have no idea if this is the case with P4V, but it absolutely is the case with a few other things I use.
Okay, too late to edit, but I decided to take a look.
The latest version of P4V actually is using Qt6, so I guess I have to stand somewhat corrected.
I'm just bitter about a couple of apps I use that are all permanently stuck on Qt4 where the vendor seems to have zero intention of caring to ever update them to a newer version of Qt. And ever since getting a HiDPI display, this has been continuously irritating me.
Personally I'd still advocate for Delphi / C++Builder there. The VCL (WinAPI wrapper plus very extensible for custom controls) behaves 'natively' because it is. And it's very nice to use.
Yep, this is a difficult problem. I wrote extensively how I managed to solve this by creating my block editor from scratch using Qt C++ and QML[1]. I faced similar issues - selection between discrete blocks, showing the underlying Markdown under the cursor, varying delegate sizes, etc.
I'm using what I learned to create a native LLM client with a streaming Markdown parser[2].
