SwiftUI vs UIKit in 2026: which do new iPhone apps use?

By Sigsten Gustavii· 14 September 2026· Updated 26 October 2026· 8 min read

If you look into making an iPhone app, two names come up again and again: SwiftUI and UIKit. Both are Apple's, both are written in Swift today, and both make native iPhone apps. They are not competing products so much as two generations of the same idea: how an app turns code into the screens you tap.

This post explains what each one is, how they differ in practice, why they mix happily in the same app, and what it means if an AI is writing your code. No adoption statistics here; Apple does not publish them, and guesses are not worth repeating.

What UIKit is

UIKit is the framework iPhone apps have been built on since the iPhone SDK appeared. It gives you windows, views and view controllers, and you manage them step by step: create a label, set its text, add it to the screen, and when the data changes, update the label yourself. That style is called imperative, because you tell the app what to do at each moment.

UIKit is mature, very flexible and has a huge amount of existing code and knowledge around it. Many large, older apps are built on it, and Apple still documents and updates it.

What SwiftUI is

SwiftUI arrived in 2019 with iOS 13. Instead of changing the screen step by step, you describe what the screen should look like for a given state, and SwiftUI updates it whenever the data changes. That style is called declarative. A list of habits is simply "a list of these habits, each with a tick"; when a habit is ticked, the screen follows.

SwiftUI code is usually much shorter, and Xcode can show a live preview of a screen while you write it. Apple uses SwiftUI across all its platforms, and Apple's own courses for new developers teach it.

SwiftUI vs UIKit at a glance

They work together

You do not have to choose one forever. Apple built bridges in both directions:

• SwiftUI inside UIKit: a UIKit app can show a SwiftUI screen with a hosting controller, so older apps can adopt SwiftUI one screen at a time.
• UIKit inside SwiftUI: a SwiftUI app can wrap a UIKit view or view controller with a representable type when it needs something UIKit does that SwiftUI does not cover yet.

So the practical question is not "SwiftUI or UIKit" but "which one is the default, and where does the other one help". For a new app in 2026, the default is SwiftUI.

Which should a new iPhone app use?

Choose SwiftUI when

• You are starting a new app, or a new screen.
• You want less code to read, change and maintain.
• You want the app to feel current, with Apple's own controls and animations.
• You might bring the app to iPad or Mac later.
• An AI is writing most of the code for you.

Choose UIKit when

• You are maintaining an existing UIKit app and the screen already lives there.
• A specific control you need exists only in UIKit; wrap it, and keep the rest in SwiftUI.
• Your team's experience is entirely in UIKit and the deadline is tomorrow.

What it means when AI writes the code

When a person writes an app, the choice of framework is partly taste and habit. When an AI writes it, a few things tip the balance clearly towards SwiftUI:

1. Shorter code is easier to change correctly. A request like "add a note to each item" touches a few lines of SwiftUI, where UIKit may need changes in several classes.
2. The screen follows the data. Declarative code avoids a whole family of bugs where the screen and the data disagree, the kind that are hard to spot in a quick test.
3. It is what Apple documents for new work. Apple's tutorials and sample code for new developers are SwiftUI, so that is the code an AI has the clearest reference for.
4. The compiler checks it. Xcode compiles the SwiftUI and catches mistakes before you ever see the app.

That is why Borel writes every app in SwiftUI. It compiles with Xcode on Borel's Mac and opens in Apple's iOS Simulator in your browser, so every change is checked by Apple's own tools before you tap it. Read more about Borel as an AI SwiftUI app builder.

Try it: a SwiftUI app from a sentence

The quickest way to see what SwiftUI code looks like is to have an app written for you and then read it. Describe something small and specific:

Make an iPhone app that keeps a list of books I want to read.
Each book has a title, an author and a status: want to read, reading, finished.
Show them grouped by status, with a swipe to move a book on.
Add a search, and a simple count of books finished this year.
Use Apple's standard look, with a soft green accent.

Borel starts with 5 free credits a day, up to 30 a month. When the app is running, you can download the SwiftUI project and open it in Xcode on a Mac to read it line by line. For examples of what SwiftUI apps can be, see SwiftUI app examples.

The same screen, two ways

To make the difference concrete, take a simple screen: a list of tasks where tapping a task ticks it off. In UIKit you set up a table view, tell it how many rows there are, build each cell, respond to the tap, update the data, and then tell the table to reload the row. Each step is code you write and keep in step yourself.

In SwiftUI you write a list of the tasks, each row showing its title and a tick, and a tap that flips the task's done value. When the value changes, SwiftUI redraws the row on its own. There is no separate step to keep the screen and the data in agreement, because the screen is described from the data.

Neither way is wrong. UIKit's step-by-step control is why it handles some very custom screens so well. SwiftUI's description is why a typical app screen needs far less code, and why changes to it are smaller and safer.

What this means if you are not a developer

If you are making an app with an AI builder, you will rarely see either framework directly. What you will notice is the result: an app that looks and behaves like the apps Apple makes, with standard navigation, lists, sheets and controls, that respects the iPhone's text size, dark mode and accessibility settings. Both frameworks give you that; SwiftUI gives it with code that an AI can change in small, checkable steps.

It also matters for the long run. If you ever hand the project to a developer, a SwiftUI codebase is what most iPhone developers learning today know, and it opens in Xcode as a normal project.

Common mistakes

• Thinking SwiftUI is not ready. It has been Apple's framework since 2019 and Apple teaches it to new developers. For most apps it covers everything needed.
• Rewriting a working UIKit app all at once. Move screen by screen with a hosting controller instead.
• Mixing styles inside one screen without a reason. Wrap UIKit where it adds something, and keep the rest declarative.
• Confusing native with cross-platform. SwiftUI and UIKit are both native; React Native and Flutter are different layers.
• Choosing by blog-post popularity. Choose by what the app needs and who will maintain it.

How to decide in five questions

1. Is the app new? Then start in SwiftUI.
2. Is there an existing UIKit codebase? Keep it, and add new screens in SwiftUI with a hosting controller.
3. Does a screen need something only UIKit offers? Wrap that one piece and keep the rest declarative.
4. Who will maintain it? If it is an AI builder or a developer learning today, SwiftUI is the shared language.
5. Will it run on iPad or Mac later? SwiftUI carries across Apple's platforms with the least change.

The bottom line

SwiftUI and UIKit are both Apple's, both native and both supported. UIKit is the older, imperative foundation with years of code behind it. SwiftUI is the newer, declarative default that Apple teaches and that new apps should start with, reaching for UIKit pieces when they need them.

If you would rather not write either by hand, describe your app on Borel and it writes the SwiftUI for you. To see the whole process, read how to make an iPhone app with AI.

We picked SwiftUI for every Borel app because it is the framework Apple teaches and keeps building on. I think a new app should start there, and reach for UIKit only when it has a reason to.

– Sigsten

Make your iPhone app in Borel

Describe the app you want and see its first screens before you pay anything.