SwiftUI 1 was a demo. SwiftUI 6 is a mature framework. Here is what changed and which apps can finally go SwiftUI-only.
When SwiftUI shipped in 2019 it was a beautiful demo and a frustrating production experience. By Swift 6 and iOS 18 the framework has matured to the point where new apps can ship UIKit-free without compromising. Here is the state of play.
What changed since SwiftUI 1
The early pain points — list scrolling jank, navigation bugs, missing APIs for keyboard handling, weak animation primitives — are mostly gone. The Observation framework replaced the awkward @StateObject dance. Lazy stacks, scroll position binding, and proper navigation stacks all work now.
When to go SwiftUI-only
- New apps targeting iOS 17+ with standard navigation patterns.
- Apps with simple to moderate scrolling lists.
- Apps where the design vocabulary is "stock iOS, well-executed."
- Apps where the team is small and DRY across platforms (iPad, Mac Catalyst, visionOS) matters.
When you still need UIKit
- Custom collection view layouts (compositional layouts are easier in UIKit).
- High-performance camera or AR scenes — drop into UIViewRepresentable.
- Very dense data tables with thousands of rows — UIKit's diffable data sources still scroll smoother.
- Apps that ship to iOS 16 or earlier (limited SwiftUI APIs).
The hybrid pattern that works
Wrap UIKit components inside SwiftUI views with UIViewRepresentable and UIViewControllerRepresentable. Keep the navigation graph in SwiftUI, drop into UIKit only for the screen that needs it. This is how Apple's own apps are built today.
What we ship
For new client projects we default to SwiftUI on the screen and Combine or Observation for state. We measure scroll performance with Instruments before shipping. Less than five percent of screens have needed a UIKit fallback in the last year.