SwiftUI shipped in 2019. Seven years later, the question is no longer "is it ready?" but "when should we use it?" After building production iOS apps with both frameworks across fintech, healthcare, and enterprise clients, we have a clear answer: it depends on the screen.
Not the project. The screen. Most production apps in 2026 use both frameworks. The question is where the boundary sits.
Where SwiftUI Wins
Forms and settings screens. SwiftUI's declarative syntax makes form-heavy screens trivial. A settings page with toggles, pickers, and text fields that takes 200 lines in UIKit takes 40 in SwiftUI. State binding eliminates an entire class of bugs where the UI falls out of sync with the data.
Lists and data display. List and LazyVStack handle large data sets efficiently. Combined with @Observable (introduced in iOS 17), the data flow is clean and predictable. We use SwiftUI for transaction history screens, notification feeds, and dashboard views.
Rapid prototyping. When a client needs to see a working prototype in days rather than weeks, SwiftUI delivers. Preview builds let us iterate on layouts without compiling and running. We can demonstrate three layout options in the time it takes to build one in UIKit.
Animations and transitions. SwiftUI's built-in animation system is simpler and more composable than UIKit's. Matched geometry effects, spring animations, and transitions work with minimal code. For microinteractions and state-driven animations, SwiftUI is the clear choice.
Where UIKit Still Wins
Complex collection layouts. UICollectionView with compositional layout handles grids, nested sections, orthogonal scrolling, and self-sizing cells with production-grade performance. SwiftUI's LazyVGrid is adequate for simple grids but falls apart on complex, multi-section layouts with heterogeneous cells.
Text editing. Any screen with rich text input, attributed strings, or custom text selection behavior needs UITextView. SwiftUI's TextEditor is a wrapper with limited customization. For a healthcare app where clinicians enter structured notes, we use UIKit for the editor and SwiftUI for everything around it.
Camera and media capture. AVCaptureSession integration requires UIKit. SwiftUI can host it via UIViewRepresentable, but the capture logic, preview layer management, and permission handling are all UIKit code. The SwiftUI wrapper adds a layer without removing complexity.
Fine-grained scroll control. If you need to programmatically control scroll position, detect scroll offsets for header collapse effects, or implement pull-to-refresh with custom animations, UIScrollView gives you the control. SwiftUI's ScrollView has improved significantly but still lacks delegate-level precision.
The best iOS apps in 2026 are not pure SwiftUI or pure UIKit. They use each framework where it is strongest.
The Hybrid Architecture
Our standard approach for new iOS projects:
- Navigation: UIKit's
UINavigationControlleras the root coordinator, with SwiftUI views hosted viaUIHostingController. This gives us full control over navigation transitions and deep linking while letting individual screens be SwiftUI. - New screens: Default to SwiftUI unless the screen requires UIKit-specific capabilities.
- Complex components: Build in UIKit, wrap with
UIViewRepresentable, expose a clean SwiftUI interface. - State management:
@Observableclasses shared across both frameworks. UIKit view controllers observe the same state objects as SwiftUI views.
This is not a compromise. It is an architecture that leverages the strengths of both frameworks. The boundary between SwiftUI and UIKit should be invisible to the user.
Migration Strategy for Existing Apps
For clients with existing UIKit codebases, we do not recommend a rewrite. We recommend incremental adoption:
- Phase 1: New screens are built in SwiftUI. Existing screens stay in UIKit.
- Phase 2: Simple existing screens (settings, profile, about) are rebuilt in SwiftUI during normal maintenance cycles.
- Phase 3: Complex screens are evaluated individually. Some are worth rebuilding. Many are not.
The goal is never "100% SwiftUI." The goal is the best tool for each screen, migrated at a pace that does not disrupt feature delivery.
What About iOS 17+ Only?
If your app targets iOS 17 and above, SwiftUI becomes significantly more capable. @Observable replaces the awkward ObservableObject pattern. NavigationStack with type-safe paths works reliably. ScrollView gains scroll position reading. The gap between SwiftUI and UIKit narrows considerably.
For enterprise apps where the minimum deployment target is typically iOS 16 or 17, this is realistic. For consumer apps that need to support iOS 15, some of these APIs are unavailable and the hybrid approach becomes even more important.
Our Recommendation
Start new projects with SwiftUI as the default, UIKit as the escape hatch. Migrate existing projects incrementally, screen by screen. Never rewrite a working UIKit screen just because SwiftUI exists.
If you are starting an iOS project or planning a SwiftUI migration, reach out. We will assess your codebase and recommend the right approach for your timeline and team.
Jean-François Duval
Lead iOS Developer at DEVSFLOW Technologies