No, List still has some awful performance cliffs unless you go out of your way to model your infinite lists in a way it can handle. There are some nice UI / NSTableView / CollectionView wrappers nowadays though.
Re:9 years of Apple text editor solo dev
by interactivecode on Friday January 05, 2024 @12:42PM
(#38881983)
The great strength of SwiftUI is that until they have caught up with UIKit and AppKit you can just drop down to those frameworks. So you can use SwiftUI in 95% of your app and where you run into limitions you can use the lowerlevel NSCollectionView for example. Whats even cooler is that inside that NSCollectionView you can just use SwiftUI views again.
That has some unique edge cases as we have been discovering when you interleave UIKit and SwiftUI together.
I kind of wish that SwiftUI was a clean break in some ways and did not depend on UIKit and avoid all the abstraction leak issues that have been arising as a result. I know that would never happen in practicality although.
I wish Apple had stuck to Model-View-Controller instead of shoehorning React philosophy into their native UI framework. Personally, I find the "old-school" way of doing things far easier to follow and understand.
The existing UIViewController and how it's implemented breaks the model-view-controller pattern, so there was nothing to stick to.
React is popular for a reason. Declarative UI is a million times easier to implement and maintain. If a total newbie had to learn UIKit and SwiftUI then pick one, they'd pick SwiftUI 100% of the time.
The APIs for NSTableView and NSCollectionView, in contrast, were always very responsive and performant when used in the default way.
All of this greatly reduced my trust in SwiftUI. Seems like they did not have performance in mind in the core design decisions of the framework, and only tested it on small data sizes.
Maybe things have improved since then.