Apple introduced SwiftUI in 2019, and every year since it has gained features that once required UIKit. New Apple platform features, widgets, and samples increasingly arrive SwiftUI first. UIKit has not gone anywhere, though. It still powers a huge number of apps and remains the better tool for some jobs. For a new project or a team planning its next few years, the useful question is how much of each to use. Here is how we decide.
The Core Difference
UIKit is imperative. You create view controllers and views, lay them out with Auto Layout, and update them when data changes. SwiftUI is declarative. You write a view body that describes the UI for the current state, and SwiftUI updates the screen when that state changes. The same idea is behind Jetpack Compose on Android and React on the web, which makes SwiftUI easier to pick up for developers coming from those platforms.
Side by Side
| Area | SwiftUI | UIKit |
|---|---|---|
| Speed of building standard screens | Fast, with little code and live previews in Xcode | Slower, with more code for layout and updates |
| Fine control over layout and animation | Good and improving, with some edge cases that are hard to control | Complete control, mature and predictable |
| Very large or complex lists | Usually fine, but tuning can be harder | UICollectionView with compositional layout is proven at scale |
| Multiplatform | Shares much UI code across iOS, iPadOS, macOS, watchOS, and visionOS | iOS and iPadOS, with Mac Catalyst for the Mac |
| Newest platform features | Often SwiftUI first or SwiftUI only, such as widgets | Still supported, but some features arrive later or not at all |
| Hiring and existing code | New developers often learn it first | Most older codebases and many senior developers rely on it |
Your Minimum iOS Version Decides a Lot
Many of the SwiftUI features that make it pleasant in production arrived in later releases. NavigationStack came with iOS 16, and the Observation framework with the @Observable macro came with iOS 17, making state handling simpler and more efficient. If your app must still support older iOS versions, you will hit gaps and need workarounds or UIKit. Check your analytics. Most iPhone users update quickly, so supporting the last two major versions is common, but business apps used on older company devices may need more.
You Can Use Both
- UIHostingController puts a SwiftUI view inside a UIKit app, so existing apps can build new screens in SwiftUI.
- UIViewRepresentable and UIViewControllerRepresentable wrap UIKit components for use in SwiftUI, for example a camera view or a map with custom behaviour.
- Shared models, networking, and business logic do not depend on the UI framework at all, so they move between the two unchanged.
How We Decide
- 1New app with a recent minimum iOS version: SwiftUI by default, with UIKit wrapped in for the few components that need it.
- 2Existing UIKit app: keep it, and build new screens and features in SwiftUI through UIHostingController.
- 3App with heavy custom drawing, complex text editing, or demanding scroll performance: UIKit for those screens, SwiftUI around them.
- 4Team with mostly UIKit experience: plan time for learning, since thinking in state takes a few weeks to feel natural.
What to Learn First
For someone starting iOS development today, learn Swift well, then SwiftUI, including state with @State, @Binding, and @Observable, navigation, lists, and async data loading with async and await. Then learn enough UIKit to read existing code, understand view controller lifecycle, and wrap UIKit views when needed. Most job openings involve some of both, and developers who are comfortable crossing between them are the most useful on real projects.
SwiftUI is where Apple is heading. UIKit is where much of the existing code lives. A good iOS team is fluent in both.
Our iOS Swift training starts with SwiftUI and the Observation framework, then covers UIKit interoperability, so participants can work on new apps and maintain existing ones.
Key takeaways
- SwiftUI is declarative and faster for most screens, while UIKit gives complete control and is proven at scale.
- Your minimum iOS version matters, since features like NavigationStack and @Observable need iOS 16 and 17.
- Both frameworks work together through UIHostingController and the Representable protocols.
- Default to SwiftUI for new apps, and add SwiftUI screens gradually to existing UIKit apps.
- Learn Swift and SwiftUI first, then enough UIKit to read and extend older code.
