SwiftUI vs UIKit for New Apps

SwiftUI has moved from "promising" to "the default" for new iOS work. That does not make UIKit obsolete — there are still categories where it is the correct choice, and knowing which is worth more than a blanket recommendation.

SwiftUI has moved from "promising" to "the default" for new iOS work. That does not make UIKit obsolete — there are still specific categories where it is the correct choice, and knowing which is worth more than a blanket recommendation.

The short version

For a new app targeting recent iOS versions, start in SwiftUI. Drop to UIKit for the specific screens that need it. This mixed approach is well supported, widely used, and avoids committing the whole project to either extreme.

Where SwiftUI clearly wins

Development speed
Substantially less code for equivalent interfaces, and live previews shorten the edit-check loop considerably.
Multi-platform Apple products
The strongest argument. Meaningful sharing across iOS, macOS, watchOS, and visionOS from one codebase, while staying fully native.
State management
Declarative binding removes a whole category of bugs where the interface and the underlying data drift apart.
Accessibility and system behaviour
Dynamic Type, dark mode, and accessibility support are largely automatic rather than manual work.
It is where Apple is investing
New frameworks increasingly arrive SwiftUI-first. Building in UIKit today means adopting new capabilities later.

Where UIKit still wins

Very large or complex collections
UIKit's collection and table views remain more predictable at scale, with finer control over cell reuse and scroll performance.
Highly custom gestures and transitions
Interactive, interruptible, custom-timed interactions still have more precise control in UIKit.
Camera and media interfaces
Anything built around AVFoundation typically involves UIKit at some layer. Our own dual camera work sits here.
Supporting older iOS versions
If you must support several versions back, SwiftUI's earlier releases had rough edges and missing pieces that make UIKit safer.
An existing large UIKit codebase
Adding SwiftUI screens to a UIKit app is sensible. Rewriting a working app for its own sake rarely is.

Mixing them

The two interoperate deliberately well. SwiftUI views can be hosted inside UIKit, and UIKit views can be wrapped for use in SwiftUI. In practice most serious apps do both: SwiftUI for the majority of screens, UIKit for the two or three that need it.

The practical advice is to avoid deciding globally. Decide per screen, and let the hard screens use whatever suits them. A project that mandates one framework everywhere ends up fighting it somewhere.

Deployment target: the decision that actually matters

How far back you support constrains everything else, and it is often decided by default rather than deliberately.

Each iOS version you support beyond the current two or three adds testing burden and removes capabilities you could otherwise use. SwiftUI in particular improved substantially across releases, so a low deployment target means working with its weakest form.

Check your actual user base rather than assuming. For most consumer apps, adoption of the latest iOS is fast, and supporting several versions back costs more in engineering time than it earns in reach. For enterprise deployments the calculation can differ, since device refresh cycles are slower.

What this means for hiring and maintenance

Worth considering if you are commissioning rather than writing the code. SwiftUI is a smaller, newer skill set, and deep UIKit experience is more common among senior developers. In practice any competent iOS engineer works in both, but a team's default matters for how quickly they move.

For maintenance, SwiftUI's brevity generally helps — less code is less to maintain — but its rapid evolution means patterns from two years ago are sometimes no longer idiomatic. UIKit is more stable in that respect.

What we do

New work starts in SwiftUI unless there is a specific reason not to. Our own apps span iOS, macOS, and watchOS, where SwiftUI's cross-Apple sharing is the single largest practical benefit. Where we need precise camera control, we use UIKit and AVFoundation for those parts and host them inside SwiftUI.

That mixed approach is what we would recommend for almost any new project: SwiftUI as the default, UIKit where it earns its place.

Frequently asked questions

Should I use SwiftUI or UIKit for a new app?

Start in SwiftUI for a new app targeting recent iOS versions, and drop to UIKit for the specific screens that need it. This mixed approach is well supported and avoids committing the entire project either way.

Is SwiftUI production ready?

Yes, for new apps on recent iOS versions. Apple increasingly ships new frameworks SwiftUI-first, and it is where ongoing investment is going.

When is UIKit still the better choice?

For very large or complex collection views, highly custom interactive gestures and transitions, camera and media interfaces built on AVFoundation, supporting older iOS versions, and extending an existing large UIKit codebase.

Can SwiftUI and UIKit be used together?

Yes, they interoperate deliberately well. SwiftUI views can be hosted in UIKit and UIKit views wrapped for SwiftUI. Most serious apps use both, deciding per screen rather than globally.

How far back should a new app support iOS?

Usually the current two or three versions. Each additional version adds testing burden and removes capabilities, and SwiftUI improved substantially across releases so a low target means working with its weakest form.

Does SwiftUI work across Apple platforms?

Yes, and this is its strongest advantage — meaningful code sharing across iOS, macOS, watchOS, and visionOS while remaining fully native.

Talk to us about your build

KIDA Studios builds custom software, apps, games, AR and XR across Apple platforms, Windows, Android, web, and embedded. If you have a project in mind, a short discovery call is the fastest way to get a realistic scope and number.

Start a project