Steve Troughton-SmithBoy 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
Imagine building the two best UI frameworks in the world and then throwing it all away to chase a trend that optimizes for developer ease of use vs software quality, designed to 'look nice' on slides and originally intended for a smartwatch
Declarative syntax could have been a part of a new high-level next-gen UI framework, but to make it the whole thing was a huge mistake. Every single app is worse off for it — first-party, and third-party. We've all seen it, we all know it, even if we don't all admit it
Kyle Howells@stroughtonsmith I have a half finished blog post from years ago outlining the ways in which UIKit is too limited to build desktop class apps and what Apple needs to do make it better.
It's basically the exact opposite of SwiftUI.
My argument was more and higher level "UI widgets", more standard controls and a toolkit of inspectors, navigation, editor controls, so you could build a higher powered app, without having to build custom UI replicating the system apps all the time.
@stroughtonsmith SwiftUI managed to take a fantastic, but limited, phone based UI framework struggling to grow up onto Tablets and Desktop.
And then replace it with something even more limited, designed for a watch.
And then try to claim that was good enough for building Desktop apps too.
@stroughtonsmith Other things on my list were: Cycript style live debugging into running apps, hot reloading code, or just UI, live UI previews in Xcode.
We got 1 of those things at least... but everything else went in the opposite direction. More static, slower compile times, less dynamic access.
Óscar Morales Vivó@stroughtonsmith the whole declarative thing makes more sense to me as a replacement for Interface Builder (which never worked that great for iOS and has been bit rotting away for quite a while) than for the whole thing.
MarkV@stroughtonsmith What do you think is their best way forward?
@markv do what they should have done in the first place. Build a new public UI framework that supersedes UIKit and AppKit and allows for true universal apps that scale from Mac to visionOS to Apple Watch, port SwiftUI to use it instead (for the people who wish to continue writing apps like that into the future) and deprioritize the existing UIKit/AppKit backends, and allow the new framework to embed views from the old frameworks
John Brayton@stroughtonsmith @markv They could do this in small pieces. Start with simple things like cross-platform color APIs. Build to cross-platform table view APIs. But make them all exist in the context of UIKit and AppKit.
@johnbrayton @stroughtonsmith Agree. They could do a lot technically - but that would first require them to acknowledge internally that the path they’re on doesn’t end in success, get over it, and pivot.
I don’t know how SwiftUI is being regarded internally by Apple engineers outside the SwiftUI team, but in their external communication so far it still sounds like they’re 100% still on board this train.
I think the hard part is getting over the office politics and ego side of this.
Ky Leggiero@stroughtonsmith @markv what kind of things would you want to see from that, which you aren't seeing from SwiftUI? 
Naman@stroughtonsmith I often disagree with you about SwiftUI as I think declarative architecture is the right one to build UIs.
But I agree that it shouldn’t be *all* declarative. Every declarative UI framework needs imperative escape hatches. Today, that escape hatch is UIKit but they should be building something better.