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

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.

@radmakr.com He’s not just thinking about UIKit but also AppKit. SwiftUI is still an odd fit on macOS. Whether it was a “mistake” is of course debatable.

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.

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…

This!

This!

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

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

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

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

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.

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.

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.

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.

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! 👍

“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

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.