Home / when to use UIKit instead of SwiftUI
UIKit
When to use UIKit instead of SwiftUI
SwiftUI is the default, but a senior answer knows exactly where UIKit still wins. Naming those cases shows real production experience.
Where UIKit still wins
Reach for UIKit for complex or custom gesture handling, precise scroll and paging control, highly performance-sensitive lists and collection layouts, deep customization that SwiftUI does not expose, and mature integrations built around UIKit. Large existing codebases also stay on UIKit where a rewrite would not pay for itself.
How to frame it in an interview
Present it as choosing the right tool per surface, not a rewrite decision. Most real apps are hybrids: SwiftUI for the bulk of new screens, UIKit for the few surfaces that need control, bridged with UIViewRepresentable and UIHostingController. Being specific about which surfaces, and why, is far stronger than an ideological answer.
Go deeper than a summary
Share Your Screen works topics like this through in full: 75 solved Swift problems with tests, 9 real case studies, and 7 annotated mock interviews, so you rehearse the live round instead of just reading about it.
Frequently asked
Is UIKit dead in 2026?
No. SwiftUI is the default for new work, but UIKit still wins for complex gestures, precise scrolling, performance-critical lists, and large legacy codebases.
Should new apps mix UIKit and SwiftUI?
Often yes. Most production apps are hybrids, using SwiftUI for most screens and UIKit for the few surfaces that need finer control.