SwiftUI vs UIKit in 2025: What I Actually Use on Client Projects
After 9 years of UIKit and 4 years of production SwiftUI, here’s how I actually decide which framework to reach for on a new project.
I’ve shipped UIKit apps since iOS 7. I’ve been writing production SwiftUI since it was stable enough to trust — which, realistically, was around iOS 15. After all that time, I still get asked the same question from clients and junior devs: which should I use?
The honest answer: it depends, but less than it used to.
The State of Things in 2025
SwiftUI has matured significantly. Most of the rough edges that made it frustrating in 2020–2022 — the missing APIs, the broken List performance, the NavigationView mess — have been addressed. The NavigationStack introduced in iOS 16 finally gave us proper programmatic navigation. SwiftUI’s animation system is genuinely excellent. And @Observable (Swift 5.9+) made state management dramatically simpler.
UIKit isn’t going anywhere either. It’s still the layer that SwiftUI sits on top of, and when you need precise control — complex custom transitions, intricate gesture handling, certain table view optimisations — UIKit gives you that control directly.
How I Actually Decide
I start new projects in SwiftUI unless there’s a specific reason not to. Here’s my decision tree:
Use SwiftUI when:
- The minimum deployment target is iOS 16 or later
- The app is data-driven with standard UI patterns (lists, forms, detail views)
- You’re a solo dev or small team that needs to move fast
- The design doesn’t require deeply custom components
Reach for UIKit when:
- You need iOS 14/15 support and the SwiftUI bugs on those versions will hurt you
- The app has complex, heavily customised UI (think a full-screen camera editor, a drawing canvas, a custom video player)
- You’re integrating with a large existing UIKit codebase — don’t mix frameworks more than necessary
- You need precise layout control that Auto Layout handles better than SwiftUI’s layout system for your specific case
The Interop Reality
In practice, most projects I work on now are SwiftUI-first with UIKit components embedded where needed via UIViewRepresentable and UIViewControllerRepresentable. This works well. The seams are mostly invisible to users.
The one thing I’d warn against: fighting SwiftUI to make it behave like UIKit. If you catch yourself trying to replicate viewDidAppear lifecycle exactly, or manually managing frames, you’re working against the framework. Either embrace the SwiftUI model or use UIKit for that component.
What I Tell Clients
New greenfield app, iOS 16+? SwiftUI, no question. Existing UIKit app that needs new features? Add them in UIKit, unless you’re planning a longer rewrite. iOS 15 target with a tight deadline? UIKit — the SwiftUI quirks on iOS 15 will cost you time.
After 9 years of UIKit, I don’t miss it when I’m writing SwiftUI. But I’m also not evangelical about it. Use the right tool.
