> I've noticed that developers who started with UIKit really have a hard time working with SwiftUI.

I think this is true. SwiftUI became "very good" as of iOS 26 (in part because the performance gap mostly evaporated) and continues to get better in iOS 27. Over and over, I see UIKit developers trying to do things "the UIKit way" in SwiftUI, and they'd rather write TFAs instead of considering that they may need to skill up and learn to write effective and idiomatic SwiftUI.

Apple has been adding Observable support to UIKit as well, so it's easier than ever for state to be the source of truth in UIKit too. Anyone writing more than simple UIKit apps has known that for a long time, it's just big a huge pain to actually implement without a lot of custom code or a dependency like RxSwift. If Apple had embraced reactive programming 15 years ago, SwiftUI would be UIKit's new layout system, not a whole new API.

Personally, SwiftUI makes the 80% so much easier that, even if the remaining 20% requires dropping down to UIKit, it's worth it.

More or less the same happened with ObjC vs. Swift when it came out, I think.

It’s also not possible to make super bespoke interfaces without going against the grain of the framework: anathema to old school AppKit and UIKit devs.