When I tried using SwiftUI, the performance for scrolling through lists past a certain size was very painful. I guess there were ways to mitigate this slowness, but they were very unintuitive and did not give me confidence in the developers commitment to keeping apps snappy and responsive.

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.

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.

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.

Until the input data gets larger and the performance grinds to a halt.

I've released a SwiftUI app, but was a nightmarish experience. They are experimenting and changing stuff to better serve SwiftUI philosophy, like the change from Combine to Observation. There were plenty of bugs and some of them difficult to debug like previewing screens on Xcode, sometimes it keeps crashing. When it works it's marvelous. I hope they can stabilize it.

You can still use Combine in Swift, but I agree Observation in general feels inferior for all but the most mundane cases.

It's like you go through a SwiftUI tutorial placing @Published and @ObservedObject everywhere, and then once you're writing the app you realize what you need is Combine except you haven't learned that yet

> I'd be quite interested in Rich Siegel's take (the guy behind BBEdit). He's been at it, a while, as well.

Looking inside the BBEdit app, I see some Swift in BBEdit.app/Contents/Frameworks/CandiedYams.framework, which appears to be a third-party framework (CFBundleIdentifier org.darkrainfall.candied-yams), but not much else.

Not surprising.

I've been using BBEdit for about thirty years. It's been through many changes. I suspect that he's pretty conservative.

SwiftUI is pretty good, I've been using to build an app. The big problem is navigation and state handling, it's not intuitive (although I never used AppKit or UIKit so I can't say if it's better or worse)

Yeah, you really need to combine SwiftUI with a dedicated architecture like PointFree's Swift Composable Architecture. It solves your state and navigation problems while adding dependency and testing solutions as well.

Apple's stubborn and bizarrely proud insistence on not providing the full solution here is very annoying.

just had a look at Composable Architecture, and it looks like swiftUI being the equivalent of react, they faced the same problem and someone developed a redux in swift. Am i correct ?

Kind of, but without the reactive UI bits, since SwiftUI already provides that (they provide a way to publish state into the older frameworks as well). It's heavily inspired by Elm and React but doesn't match 1:1 with either.

> The big problem is navigation and state handling

Those seem like very basic features that a UI framework needs to get right.

Apple seems to think the UI frameworks should only focus on UI, and so overall arch is an afterthought. You can, of course, navigate and store state using the tools provided, but it's a pain to do so beyond local screens, where you have to manually pass things around, and you lose most testability.

You should give it an other go building on SwiftData and the new Observation API’s. They made leaps and bounds and it’s so much better now!

I’m having a lot of fun with it at the moment. If you stay within the bounds of how they encourage you to build the apps, you can just go go go and with very little work release a fast, stable, native app across all their platforms.

I follow the development of Swiftcord, A SwiftUI Discord client, on the developer's discord, and they almost constantly lambast how much is apparently missing or unstable between AppKit and the current version of SwiftUI, which has made it a struggle to get to feature parity with the official Discord client based on Electron cause lots of things you expect either have to be implemented by hand or just can't be done IIRC.

Why do they insist on making their life harder? Just use Cocoa...

Well, migrating swift versions was not too fun