Was SwiftUI a mistake? Steve Troughton-Smith writes on Mastodon:

Boy do I wish Apple had built a real Apple-quality next-gen UIKit/AppKit-like first-party cross-[Apple]-platform UI framework instead of SwiftUI. The closest thing Apple makes is still Catalyst, but they completely squandered their opportunity to make something better than what came before. Going all-in on SwiftUI is the kind of mistake that will hurt for decades to come

This is a frequent topic on Core Intuition. For the Mac, there are pros and cons for choosing AppKit, Catalyst, or SwiftUI. It shouldn’t be that way.

@manton SwiftUI is so much better than UIKit. I don’t understand these takes that Steve is sharing here..

@manton He issues I tend to see in swiftUI are in the bridges were it depends on UI kit or AppKit. It would be so much better if it removed the dependency on this apis as there is so much complexity in mapping a declarative state to these older imperative APIs.

@manton I don’t know AppKit or macOS development very well. But in that case, Apple needs to take SwiftUI on macOS more seriously.

@manton It's pretty excellent for prototyping.

You then might even be able to get ChatGPT or Claude to convert a SwiftUI view to expanded UIKit code without too many bugs. Too bad Xcode doesn't do that kind of rewriting itself.

@alexr Would’ve been interesting if SwiftUI had started as purely an Interface Builder replacement, mostly for layout. It’s such a huge task to replace everything UIKit and AppKit can do.

@manton It feels like the software equivalent of the butterfly keyboard. Good ideas, but the implementation has apparently unfixable flaws, and Apple is pretending everything is fine.

@manton He was against SwiftUI from the beginning, because he was so hyped about Marzipan/Catalyst coming and about “iOS and UIKit eating the Mac”, that when SwiftUI suddenly launched and it became clear to everyone else that Catalyst is a transitional thing, he kept convincing himself otherwise…

@manton

@manton This!

@manton This!

@manton But basically everything relies on UIKit/AppKit? AFAIK the only things that are fully rendered by SwiftUI are labels, images, and shapes

@manton SwiftUI gave us this. The most in-Mac app to ever exist

@manton How would that even work? Apple would have to maintain three different UI frameworks UIKit, AppKit, and a completely separate SwiftUI backend that behaves differently on Mac and iOS. They can’t abandon UIKit or AppKit, and a standalone SwiftUI would still need to perfectly replicate their behavior

@manton How would that even work? Apple would have to maintain three different UI frameworks UIKit, AppKit, and a completely separate SwiftUI backend that behaves differently on Mac and iOS. They can’t abandon UIKit or AppKit, and a standalone SwiftUI would still need to perfectly replicate their behavior

@manton Text, images, shapes etc yes. But also stuff like the animation and gesture system appear to not depend on UIKit even if they animate those objects.

@manton I would suggest they gradually replace components that wrap UIKit or AppKit with new components build purply from SwiftUI primitives (extending SwiftUI in the places that are needed to do this).

They do not need to perfectly replicate the behavior just feel close enough.

@manton After spending a decade or more learning UIKit, developers that don’t know any other framework have a lot of trouble switching to SwiftUI. They would have even more difficulty switching to a framework from another vendor. This is normal. SwiftUI is an excellent framework. Just learn it! 👍 Less code.

@manton After spending a decade or more learning UIKit, developers that don’t know any other framework have a lot of trouble switching to SwiftUI. They would have even more difficulty switching to a framework from another vendor. This is normal. SwiftUI is an excellent framework. Just learn it! 👍 Less code.

@manton For those paying attention, from now on it is SwiftUI, Swift Data and actors. Anything else will be eventually deprecated. Don’t be left behind. Learn it! 👍

@manton “Close enough” shakes head in resentment. RN seems to work fine even though it relies on UIKit. If UIKit were the problem, then SwiftUI components that don’t rely on it like LazyVStack should perform great, but they don’t. So there must be something else causing issues

@manton Lazy stack in my experience works absolutely fine so long as all of the nested components itself do not depend on UIKit or AppKit.

And I would not say RN performs well.