SwiftUI very likely is the future of app development. But it cannot, on its own replace UIKit or AppKit. Not yet, maybe not next year, either.

Eventually you will have to drop down a level to implement a custom view, custom navigation, animation, window, or what have you. So for the time being, the two worlds of UIKit and SwiftUI co-exist and complement each other.

It gets weird when you try to (or need to) bridge genuine SwiftUI objects to make them available in UIKit. The other way around is expected, but just take a look at the many hoops the folks at Moving Parts had to jump through to get SwiftUI.Font metadata info into UIKit: https://movingparts.io/fonts-in-swiftui

And I’m not even talking about the weird stuff that uses private API.

My own SwiftUI experiments are both fun and challenging, don’t get me wrong. It’s good.

I’m worried for the next couple of years, though: if cross-platform apps are to become a thing, making them good and feature-complete on every platform requires, well, platform-specific expertise plus knowledge of SwiftUI plus knowledge to bridge these worlds. You’ll need to be fluent in SwiftUI, UIKit, and AppKit. Meanwhile, because you can get 60% or more of the app’s functionality in pure SwiftUI, you will not be exposed to UIKit and AppKit as much.

Well, maybe I’m a slow learner – but I absolutely needed to immerse myself into AppKit for years to become proficient and comfortable. The time it took to create my first app is ridiculous in hindsight. I’m not sure how to learn only the parts of AppKit that you need to complement SwiftUI, for example. I’d wager it’s impossible. Either you know how AppKit works for the most part, or you don’t. So any genuine time saving of SwiftUI for cross-platform app development won’t kick in for years. Same goes for UIKit.