SwiftUI’s adoption has moved fast. Around 40% of new iOS apps were using it as their primary UI framework in 2023. By 2025 that figure had climbed to roughly 70%, and 78% of all new App Store submissions included at least some SwiftUI code.
That shift has been driven partly by Apple pushing SwiftUI hard across its platforms — it’s now the natural choice for apps targeting visionOS, watchOS and macOS alongside iPhone — and partly by the framework itself maturing to the point where it handles most production use cases without the workarounds earlier versions required.
But the legacy picture is different. Around 80% of established enterprise apps — the ones running in banks, healthcare systems, logistics — still rely on UIKit. These codebases are large, well-tested, and migrating them wholesale to SwiftUI makes no sense. So hybrid development, mixing SwiftUI for new screens and UIKit for existing ones, has become the pragmatic default.
What this means in practice: if you’re building something new, SwiftUI is almost certainly the right starting point. It’s faster to write, shares more code across Apple platforms, and the ecosystem of libraries and patterns around it is now mature. If you’re extending an existing app, a hybrid approach — SwiftUI components dropped into a UIKit shell — is standard and well-supported.
The one caveat worth knowing: UIKit still benchmarks around 5–10% faster in performance-intensive scenarios. For 95% of apps that gap is irrelevant, but if you’re building something with complex animations or very high frame-rate requirements, it’s worth a conversation about where the boundaries should sit.
For new iOS projects, our default is SwiftUI. See our iOS & Android page for how we approach native builds.