The short answer
For a new app, start with SwiftUI and reach for UIKit where SwiftUI is not yet the better tool. They are not rivals: Apple designed them to work together, and one app can mix both, screen by screen.
What each one is
UIKit
UIKit is the framework iPhone apps have been built with since the first iPhone SDK in 2008. It is imperative: you create views and view controllers, then change them step by step as things happen. It is mature, thoroughly documented, and gives complete control over every pixel.
SwiftUI
SwiftUI arrived in 2019. It is declarative: you describe what a screen should look like for a given state, and the framework updates the screen when the state changes. The same approach works across iPhone, iPad, Mac, Apple Watch, Apple TV and Apple Vision Pro.
Side by side
| SwiftUI | UIKit | |
|---|---|---|
| Style | Declarative: describe the screen for each state | Imperative: create views, then update them |
| Introduced | 2019, with iOS 13 | 2008, with the first iPhone SDK |
| Building speed | Faster for most screens, with live previews in Xcode | More code for the same screen |
| Fine control | Good, and wider every year | Complete |
| Widgets and Live Activities | Built with SwiftUI | Not available |
| Platforms | Every Apple platform | iPhone, iPad, Apple TV and Vision Pro; Mac through Catalyst |
| Older iOS versions | Newer features need newer iOS | Reaches far back |
Where SwiftUI is the better choice
- Most screens of most apps. Lists, forms, settings, onboarding and detail views take less code, have fewer bugs and are quicker to change.
- Interfaces that reflect data. When a screen should simply show your data, SwiftUI removes a whole class of out-of-sync bugs. Since iOS 17, the Observation framework makes this simpler still.
- Animation. Transitions and spring animations take a line or two.
- Widgets, Live Activities and other system surfaces. These are built with SwiftUI.
- Previews. Xcode previews show a screen in many states without running the app.
Where UIKit still matters
- Complex text and scrolling layouts. Rich text editing, very large or unusual collection layouts and fine-grained gesture handling are still easier to get exactly right in UIKit.
- Existing codebases. A large, working UIKit app does not need a rewrite. New screens can be written in SwiftUI inside it.
- Older iOS versions. Many SwiftUI features depend on the iOS version:
NavigationStackneeds iOS 16 and the Observation framework iOS 17. Supporting older devices narrows what SwiftUI can do. - Views that only exist in UIKit. Some system views and behaviours have no SwiftUI equivalent yet, and are wrapped for use from SwiftUI.
Using both in one app
Apple provides bridges in both directions, so the decision is made per screen, not per app:
- UIKit inside SwiftUI:
UIViewRepresentableandUIViewControllerRepresentablewrap a UIKit view or view controller for use in a SwiftUI screen. - SwiftUI inside UIKit:
UIHostingControllerplaces a SwiftUI view in a UIKit app, which is how most teams begin a migration.
Moving an existing UIKit app to SwiftUI
Rewrites are expensive and rarely necessary. A safer path:
- Build every new screen in SwiftUI, hosted inside your existing navigation.
- Move simple, self-contained screens next: settings, onboarding, empty states.
- Leave complex, stable screens in UIKit until there is a reason to change them.
- Raise the minimum iOS version when your audience allows it, which opens up more of SwiftUI.
How we approach it
Our default for new apps is SwiftUI, with UIKit for the pieces where it is still the better tool. Every line is Swift; we do not use cross-platform frameworks. If you are weighing native against React Native or Flutter rather than SwiftUI against UIKit, read Native Swift vs React Native and Flutter.
Related: iOS app development · How much an iOS app costs · Native Swift vs React Native and Flutter · React Native to Swift migration