Seven years after SwiftUI's debut, the "which iOS framework should I use" question still doesn't have a one-size-fits-all answer. SwiftUI has matured dramatically. UIKit is still everywhere. And the real-world apps we build for clients routinely use both. This guide covers how we think about the choice in 2026 — what each framework does well, what still pulls us back to UIKit, and how to structure a codebase that uses both without creating a maintenance swamp.
Where SwiftUI Has Genuinely Won
SwiftUI's declarative model has become the default starting point for most new iOS projects we scope. The reasons are practical, not ideological.
- Speed of building standard screens: Lists, forms, settings pages, and profile views that used to take two days in UIKit often take two hours in SwiftUI.
- Live previews: Xcode previews shorten the write-compile-run cycle for visual work from 20-30 seconds to sub-second. On a big app, that compounds into hours per day.
- Cross-platform reuse: A single view definition can render on iPhone, iPad, Mac, Apple TV, and Apple Watch with modifiers handling the differences.
- State management baked in:
@State,@Binding,@Observable, and@Environmentreplace a pile of delegate protocols and notification patterns. - Accessibility by default: Standard SwiftUI components come with VoiceOver labels, dynamic type support, and proper trait handling out of the box.
Where UIKit Still Wins
UIKit is not a legacy framework. Apple continues to ship UIKit-first APIs, and several categories of work still pull us back to it.
- Highly custom scroll and gesture behavior: SwiftUI's scroll views have improved, but any app with custom snapping, velocity-based animation, or layered gesture handling is still faster and more reliable in UIKit.
- Camera and AR interfaces: AVFoundation and ARKit compose more naturally with UIKit view controllers.
- Complex compositional collection views: UICollectionView with compositional layouts still beats SwiftUI's equivalent for performance and flexibility at scale.
- Deep third-party SDK integration: Payment SDKs, video SDKs, and map customizations often ship UIKit-first or UIKit-only.
- iOS 15 and earlier support: If your app must support older iOS versions, large portions of SwiftUI's 2024-2026 feature additions are simply unavailable.
The Hybrid Approach We Actually Ship
Most apps we build ship with both frameworks. SwiftUI handles the majority of screens. UIKit handles the 15-20% of surfaces that benefit from its strengths. The interop tools make this practical.
UIHostingController
Embed a SwiftUI view inside a UIKit navigation stack. This is how we incrementally migrate older UIKit apps — ship new screens in SwiftUI while leaving stable UIKit screens alone.
UIViewRepresentable and UIViewControllerRepresentable
Wrap UIKit views or controllers to embed them inside SwiftUI hierarchies. Useful for camera previews, WKWebView, third-party player SDKs, and complex text editors that still live in UIKit.
Shared Data Layer
Keep your view models, repositories, and services framework-agnostic. They should be plain Swift that either UIKit or SwiftUI can consume. This insulates your business logic from framework churn and makes the hybrid approach sustainable.
The Decision Framework
When scoping a new iOS project, we run through four questions:
- What iOS version floor does the app need to support? iOS 17+ unlocks essentially all modern SwiftUI capabilities. iOS 15 and below forces significant compromises.
- How custom is the UI? Standard components and navigation patterns favor SwiftUI. Highly custom gesture-driven or graphics-heavy interfaces favor UIKit.
- What's the team's skillset? A team fluent in UIKit with tight deadlines should not retool mid-project. A new team starting fresh should favor SwiftUI.
- How long will the app live? Apps expected to run for 5+ years should bias toward SwiftUI because Apple's investment is clearly there.
Performance Reality in 2026
SwiftUI's performance has caught up to UIKit for the vast majority of use cases. The places where SwiftUI still lags are narrow: very large scrollable collections with heavy cell customization, and screens with dozens of nested animations running simultaneously. For the typical app — lists, forms, detail screens, tab bars — the frameworks perform equivalently.
Where SwiftUI can surprise you is in unnecessary body re-evaluations. A poorly scoped @State or overuse of @Published can cause view rebuilds that UIKit would never do. Profiling with Instruments' SwiftUI instrument catches these fast.
Common Mistakes We See
- Going 100% SwiftUI on the first try and hitting a wall. Teams new to SwiftUI often try to purist their way through and end up fighting the framework for 20% of screens instead of dropping to UIKit where appropriate.
- Scattering business logic across views. SwiftUI's ease of building views tempts developers to put business logic directly in view bodies. Keep views dumb and push logic into view models.
- Ignoring preview stability. When previews stop working because of complex dependencies, teams abandon them. A little dependency injection goes a long way toward keeping previews useful.
- Framework fundamentalism. The answer isn't SwiftUI or UIKit. It's both, used appropriately.
Frequently Asked Questions
Should I rewrite my existing UIKit app in SwiftUI?
Rarely. Incremental migration — new features in SwiftUI, existing stable features left in UIKit — delivers most of the benefit without the risk. Full rewrites almost always cost more and ship later than the team predicts, and rarely produce user-visible improvements.
Can SwiftUI handle a complex production app?
Yes, with caveats. Apps like Apple's own Shortcuts, large portions of the Fitness app, and many recent third-party launches are SwiftUI-first. The framework is production-ready for most app categories, but you'll likely mix in UIKit for specific surfaces.
What's the learning curve for a UIKit developer moving to SwiftUI?
The mental model shift is significant — declarative vs imperative, value types vs reference types for views, new state management primitives. Most UIKit developers we've worked with are productive in SwiftUI within 2-3 weeks and fluent within 2-3 months.
Open Door Digital builds native iOS apps using the right framework for each surface. Talk to our team about your mobile roadmap.
Related reading: iOS vs Android Development and React Native vs Flutter.