4 ms·

> 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

> 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 5mo ago
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 5mo ago
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.
vor_ 5mo ago
> 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.
- CharlesW 5mo ago
  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.
  - longnguyen 5mo ago
    Is that an iOS app? Because List on macOS still has a lot of performance issues. This guy run a benchmark vs. AppKit and SwiftUI is still slow in macOS26 https://github.com/lemonmojo/swiftui-hierarchical-list-performance https://github.com/lemonmojo/swiftui-hierarchical-list-perfo...
  - novok 5mo ago
    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.

silvestrov 5mo ago

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 5mo ago

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.

vor_ 5mo ago

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

CharlesW 5mo ago
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.
- longnguyen 5mo ago
  Is that an iOS app? Because List on macOS still has a lot of performance issues. This guy run a benchmark vs. AppKit and SwiftUI is still slow in macOS26 https://github.com/lemonmojo/swiftui-hierarchical-list-performance https://github.com/lemonmojo/swiftui-hierarchical-list-perfo...
- novok 5mo ago
  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.