When I was ranked #1 in the Infosys iOS cohort for UI/UX, I'd used both SwiftUI and UIKit within the same project cycle. The Library Management app was SwiftUI. The Smart Parking app mixed UIKit for the map integration with SwiftUI for everything else. The ITC Hotels prototype was pure SwiftUI animations.

Here's the framework I use when deciding which to reach for.

The Short Answer (For People Who Are Busy)

  • New project targeting iOS 16+ → SwiftUI first, UIKit only where needed
  • Existing UIKit codebase → Keep it UIKit, add SwiftUI with UIHostingController for new screens
  • Complex custom controls (video player, canvas, custom gestures) → UIKit or mixed
  • Rapid prototyping / pre-sales demo → SwiftUI, always

Where SwiftUI Genuinely Wins

Development Speed

The ITC Hotels prototype needed to look impressive in 4 days. I used SwiftUI's declarative syntax and built polished animations — parallax cards, spring transitions, custom tab bars — in a fraction of the time UIKit would have required. The preview canvas alone eliminates 60% of build-run-check cycles.

Data-Driven UIs

SwiftUI's Combine integration and @Observable (iOS 17+) make data-driven UIs feel natural. Lists that react to data changes, conditional views, forms — all dramatically less boilerplate than UIKit's delegate/datasource pattern.

Accessibility & Dark Mode

SwiftUI handles accessibility and dark mode automatically. In UIKit, you're manually overriding traitCollectionDidChange and checking UITraitCollection.current.userInterfaceStyle. SwiftUI just does it.

Where UIKit Still Wins

Fine-Grained Animation Control

UIKit's UIViewPropertyAnimator and Core Animation give you frame-level control that SwiftUI's withAnimation can't match. For the Smart Parking app's map interactions, I needed precise gesture-driven animations — UIKit was the right choice.

Third-Party SDK Integration

MapKit, AVFoundation, and most enterprise SDKs still expose UIKit-based APIs. You can wrap them in UIViewRepresentable for SwiftUI, but it adds complexity. If your app is SDK-heavy, UIKit reduces the wrapping overhead.

Performance on Older Devices

SwiftUI's view diffing algorithm occasionally causes unexpected re-renders on complex screens. On iOS 15 and older devices, complex SwiftUI list scrolling can stutter. UIKit's manual control over cell reuse and layout is more predictable at scale.

"The best production iOS code I've written uses SwiftUI for the 80% of standard UI, and UIKit for the 20% where you need the control. Don't let framework loyalty push you into the wrong choice."

The Hybrid Approach (What I Actually Do)

In practice, I use UIHostingController to embed SwiftUI views inside UIKit navigation stacks, and UIViewRepresentable to bring UIKit components into SwiftUI hierarchies. The two frameworks interoperate cleanly since iOS 13.

My typical approach for a new client app in 2025:

  1. Architecture in MVVM using @Observable (iOS 17+) or ObservableObject
  2. All list/form/content screens in SwiftUI
  3. Map, video, custom gesture screens wrapped from UIKit
  4. Navigation: SwiftUI's NavigationStack (iOS 16+) for new projects

The iOS 14 Question

If you must support iOS 14, SwiftUI's API surface is noticeably smaller and buggier. In that case, keep the main structure in UIKit and use SwiftUI only for self-contained leaf views. For iOS 16+ minimum (most new projects in 2025), SwiftUI first is the right default.