What Is SwiftUI?
SwiftUI is Apple's declarative framework for building user interfaces across all of its platforms — iOS, iPadOS, macOS, watchOS, and tvOS — using a single, shared syntax written entirely in Swift. Instead of imperatively instructing the system how to construct and mutate view objects step by step (as UIKit does), you declare what the UI should look like for a given piece of state, and SwiftUI's rendering engine figures out how to efficiently update the screen when that state changes. This shift from 'how' to 'what' is the single biggest conceptual leap developers make when moving from UIKit to SwiftUI.
Cricket analogy: Just as a captain tells a bowler to bowl a yorker at the death, what's needed, rather than dictating every muscle movement, how, SwiftUI declares what the UI should look like for a given state, and its rendering engine figures out how to update the screen.
Declarative vs. Imperative UI
In UIKit, showing a label with updated text means holding a reference to a UILabel and calling label.text = newValue whenever the underlying data changes — the developer is responsible for keeping the view synchronized with the model. In SwiftUI, a view's body is a pure function of its state: you write Text(username) once, and whenever the username property changes, SwiftUI automatically recomputes the affected part of the view tree and re-renders only what's necessary. Views in SwiftUI are lightweight, immutable value types (structs), not long-lived class instances, which is why SwiftUI can cheaply recreate them on every state change rather than mutating them in place.
Cricket analogy: Just as an old-school scorer manually erases and rewrites the scoreboard number every time a run is scored, SwiftUI's Text(username) is written once, and a lightweight, disposable scorecard, a struct, is recreated automatically whenever the underlying score changes, rather than mutating one permanent board.
import SwiftUI
struct CounterView: View {
@State private var count = 0
var body: some View {
VStack(spacing: 16) {
Text("Count: \(count)")
.font(.largeTitle)
Button("Increment") {
count += 1
}
.buttonStyle(.borderedProminent)
}
}
}How SwiftUI Renders Updates
When @State (or another observed property) changes, SwiftUI doesn't rebuild the entire screen from scratch. It re-invokes the body computed property to get a new description of the view tree, diffs it against the previous description, and applies only the minimal set of changes to the actual rendered output. This diffing process is why views must be cheap and side-effect-free: body can be called many times, and any expensive work or mutation performed there would run repeatedly and unpredictably.
Cricket analogy: Just as a video review official doesn't restart the entire match replay for every appeal but re-checks only the relevant frames and applies just the needed correction, SwiftUI re-invokes body, diffs it against the previous tree, and applies minimal changes — so body must stay cheap and side-effect-free.
A useful mental model: think of SwiftUI's body as a recipe, not a cake. You describe the recipe once; SwiftUI bakes (renders) a new cake every time an ingredient (state) changes, but only remakes the parts of the cake that actually differ.
Because body can execute many times, avoid putting expensive computations, network calls, or logging directly inside it — use .task or .onAppear for side effects instead.
- SwiftUI is a declarative, cross-Apple-platform UI framework written entirely in Swift.
- Views describe 'what' the UI looks like for given state, not 'how' to mutate it step by step.
- SwiftUI views are lightweight value types (structs), unlike UIKit's class-based view objects.
- State changes trigger SwiftUI to recompute
bodyand diff the result against the previous tree. bodyshould be pure and cheap — side effects belong in.onAppear/.task, not the view description.- SwiftUI can share UI code across iOS, macOS, watchOS, and tvOS with platform-specific adjustments.
Practice what you learned
1. What kind of Swift type are SwiftUI views typically implemented as?
2. In SwiftUI's model, what triggers a UI update?
3. Why should expensive work be avoided directly inside a view's `body`?
4. Which of these platforms can SwiftUI target?
5. How does SwiftUI's declarative approach differ fundamentally from UIKit's imperative approach?
Was this page helpful?
You May Also Like
What Is iOS Development?
An overview of what building apps for Apple's iOS platform involves, from the toolchain and languages to the App Store distribution pipeline.
Views and the View Protocol
How the `View` protocol works, what `body` must return, and how SwiftUI composes small views into larger interfaces.
@State and @Binding
Understand how @State owns local view state and how @Binding lets child views read and write that state without owning it themselves.
Modifiers in SwiftUI
How view modifiers work under the hood, why order matters, and how chained modifiers build up new wrapped view types.