SwiftUI vs UIKit in 2026: when to still pick UIKit
It's 2026 and we still get the same question on every new project: SwiftUI or UIKit. The honest answer used to be 'it depends.' In 2026 it's closer to 'SwiftUI, unless one of these specific things is true.' This post is about those specific things - the cases where UIKit is still the right call, and how to mix the two without regretting it later.
The default has shifted
On the 48 apps we've shipped, exactly zero new screens have been written in UIKit since 2024. SwiftUI's velocity advantage is real: a typical settings screen, list-detail flow, or onboarding sequence ships in a third of the time it used to.
More importantly, the gap that SwiftUI had with UIKit in 2022-2023 (broken focus, missing TextField features, weird scroll edge cases) has mostly closed. iOS 17+ landed scrolling APIs, observation, focus, and inspectors that finally feel intentional rather than retrofitted.
When SwiftUI is the easy yes
If your app is what we call a 'log family' app - list of entries, detail view, charts, settings, optional widget - SwiftUI is the unambiguous choice. BodiLog, Habit Tracker Kit, and MediLog all fit this shape and are 100% SwiftUI.
The same goes for productivity tools, calculators, and small utilities. When the bottleneck is product iteration speed, SwiftUI compounds harder than UIKit. The cost of a UI change drops by an order of magnitude.
When UIKit still wins
Three categories where we'd reach for UIKit (or UIViewRepresentable) in 2026:
- Heavy custom drawing or transitions. SwiftUI's transitions API is improved but still less precise than CATransition + UIViewControllerAnimatedTransitioning when you want full control over interactive dismissals or shared-element animations.
- Camera-driven UI. AVFoundation, ARKit, and live filters work fine in SwiftUI, but a UIViewController hosting AVCaptureVideoPreviewLayer is still simpler when you need precise frame timing or custom overlay rendering.
- Massive scroll performance under stress. A 50,000-row table that filters live still benefits from UICollectionView's diffable data sources. SwiftUI's List has improved but isn't quite there for extreme cases.
Mixing the two in 2026
We've adopted a simple rule: SwiftUI by default, UIKit when a single view needs it. The escape hatch is UIViewRepresentable at the leaf. We never invert it (SwiftUI inside a UIKit shell), because that path leads to lifecycle pain and lost accessibility tree continuity.
Concrete example: a recent app needed a barcode scanner. We wrapped AVCaptureVideoPreviewLayer inside a UIViewControllerRepresentable, then composed the rest of the screen in SwiftUI. Total UIKit footprint: ~40 lines.
Our practical rule
Start every new project in SwiftUI. The day you hit a problem SwiftUI can't solve cleanly, drop into UIKit for that one view - not the whole module, not the navigation stack, not even the parent view controller. One leaf node. Then keep going.
If you're still unsure, the cost of starting in SwiftUI and grafting in UIKit later is much lower than the reverse. Start where the velocity is.