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.
Well I've been doing this for a pretty long time and I'd like to think I'm pretty good at it.
Personally, SwiftUI makes the 80% so much easier that, even if the remaining 20% requires dropping down to UIKit, it's worth it.
> If Apple had embraced reactive programming 15 years ago, SwiftUI would be UIKit's new layout system, not a whole new API.
This is incredibly frustrating, particularly now that more UIKit and SwiftUI widgets share underlying implementations.
SwiftUI/React/etc don't introduce that pattern, they simply enforce it (and add efficiencies).
If a developer isn't familiar with the pattern, it's not because they are a UIKit dev, it's because they are inexperienced.
For example (this is pseudo-code, I haven't written Swift in a long time):
class ProfileViewController: UIViewController {
struct State: Hashable {
var username: String?
var profileImageURL: String?
}
var state = State() {
didSet {
if state != oldValue { updateView() }
}
}
// must be idempotent
// must only read state and only mutate the view
function updateView() {
usernameLabel.text = state.username
profileImageView.setImage(url: state.profileImageURL)
}
}