What is SwiftUI and how does it compare to UIKit

What SwiftUI is

SwiftUI is Apple's framework for building app interfaces in Swift. Apple introduced it on June 3, 2019, at WWDC19 alongside Xcode 11 (Apple's press release). The code is declarative. You describe what a screen is made of and how it depends on your data, say "a list of songs, each with its cover, title and artist". When the data changes, SwiftUI redraws the part that changed.

Every screen, and every piece of one, is a struct that conforms to the View protocol. Modifiers change how an element looks, for example .padding() adds spacing and .font(.title) sets the type. The same code runs on iPhone, iPad, Mac, Apple Watch, Apple TV and Vision Pro.

Where SwiftUI lives in Xcode

There is nothing to install, SwiftUI ships with Xcode and the OS. Start a project at Xcode › File › New › Project › App and pick SwiftUI for Interface (as described in Xcode Help). The file named after your app with App at the end is the entry point, and ContentView.swift is the first screen.

To the right of the code, Xcode shows the canvas with a live preview. It comes from the #Preview macro below the view, and edits in the code show up on the canvas right away.

Versions and Apple's numbers

What	Value
Introduced	June 3, 2019, WWDC19, with Xcode 11
Minimum OS versions	iOS and iPadOS 13.0, macOS 10.15, watchOS 6.0, tvOS 13.0, visionOS 1.0
UIKit, for comparison	since iOS 2.0
Liquid Glass on custom views	the glassEffect modifier, since iOS 26.0
Minimum iOS on the App Store	iOS 13, since September 9, 2026
Builds for the App Store	Xcode 26 or later, since April 28, 2026
Xcode 27	macOS Tahoe 26.6 or later, Apple silicon Macs only, Swift 6.4

Per the SwiftUI documentation, App Store upcoming requirements and the Xcode version table, checked October 16, 2026.

Since September 9, 2026, the App Store only takes apps that target iOS 13 or later, and iOS 13 is exactly where SwiftUI starts. So core SwiftUI fits any app you can upload today. Newer views arrive with each iOS release, and using them means raising your minimum version.

Your first SwiftUI screen, step by step

1. Open Xcode 26 or later and choose File › New › Project › App.
2. Enter a name, pick a signing team under Team, set Interface to SwiftUI and click Create.
3. Open ContentView.swift and describe the screen inside body, for example a VStack with a Text and a Button.
4. Check that a #Preview { ContentView() } sits below the struct and watch the canvas.
5. Add a tap counter with @State and check that the label updates by itself.
6. Pick an iPhone simulator and press Run to try the screen in a real app.

SwiftUI vs UIKit

UIKit has been around since iOS 2.0. There you build screens from view controllers and views and update them yourself when the data changes. SwiftUI takes less code, shows the result on the canvas at once, and one codebase covers iPhone, iPad, Mac and Watch. UIKit still earns its place where you need fine control over scrolling, text or a large existing codebase.

You don't have to pick one, since Apple built SwiftUI to work alongside UIKit and AppKit (SwiftUI page). UIHostingController puts a SwiftUI screen into UIKit, and UIViewRepresentable does the reverse, both since iOS 13.0.

What changed in 2025 and 2026

Since iOS 26, released on September 15, 2025, standard SwiftUI controls pick up the Liquid Glass material on their own once you build with Xcode 26. Custom views use the glassEffect modifier, more on the Liquid Glass page.

In Xcode 27, @State became a macro, so a class stored in it is created lazily, once per view lifetime (what's new in SwiftUI). The Xcode 27 coding assistant also got skills for adopting new SwiftUI features, which helps if you build with an AI agent (vibe coding).

Common mistakes

• A new view with an old deployment target. If a view arrived in iOS 17 and the project supports iOS 15, the build fails without an if #available check.
• Shared data in @State. @State holds state for one view. Data several screens need belongs in a model, otherwise the copies drift apart.
• Heavy work inside body. SwiftUI calls body on every data change, and a network load there makes scrolling stutter.

Appto writes your app in SwiftUI inside a regular Xcode project, walks through every screen on the simulator itself and fixes what it finds. You can check it by hand on the simulator, your own iPhone or through TestFlight, more on the code page.