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.

[1] https://notes.alinpanaitiu.com/SwiftUI%20is%20convenient,%20...

[2] https://x.com/daniel_nguyenx/status/1734495508746702936

[3] https://rubymamistvalove.com/block-editor#8-performance

▲

CharlesW 4 hours ago | parent | next [-]

> 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.

	▲	silvestrov 3 hours ago \| parent \| next [-]
		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.
	▲	KerrAvon an hour ago \| parent \| prev [-]
		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.

▲

StilesCrisis 5 hours ago | parent | prev [-]

Qt is the opposite of native. It's just reimplementing the look and feel of a native app, but the seams are extremely visible.

▲

jeremyjh 4 hours ago | parent | next [-]

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.

▲

tux3 3 hours ago | parent | prev | next [-]

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.

	▲	StilesCrisis 12 minutes ago \| parent [-]
		I disagree. I use P4V (Qt-based) regularly. Its lists are quirky and sometimes don't scale property with the OS DPI settings.

▲

singpolyma3 3 hours ago | parent | prev | next [-]

Unless you're on KDE where it's literally native?

▲

4 hours ago | parent | prev | next [-]

[deleted]

▲

4 hours ago | parent | prev [-]

[deleted]