What a view really is

All three have been created — each of them twice — and none has appeared. This is the console before any tap:

Detail.init for Seattle
Detail.init for Seattle
Detail.init for Vancouver
Detail.init for Vancouver
Detail.init for Atacama
Detail.init for Atacama

A NavigationLink written this way is given its destination as a view, so the destination is built when the row is built. Hacking with Swift's suggested answer to this interview question makes the same point: SwiftUI creates "all its view structs immediately, even creating destination views for navigation links".

Tapping Seattle printed one line, and going back and tapping it again printed the same line once more:

Detail appeared: Seattle

onAppear ran each time the view came onto the screen, and init did not come into it. So: an initializer stores its inputs and does nothing else. Work goes in .onAppear or .task. Apple's own advice goes further: "It's often best to omit an explicit initializer" altogether, and let Swift write it.

If even creating the destination is costly, use the form of navigation that takes a value instead of a view — NavigationLink(value:) with navigationDestination(for:) — which builds the destination only when it is needed. That is lesson 22.

Where this comes from: Hacking with Swift interview question: What’s the difference between a view’s initializer and onAppear()? · Declaring a custom view — Apple, “Declaring a custom view”: "Because the system may reinitialize a view at any time, it’s important to avoid doing any significant work in your view’s initialization code."

After the tap:

ContentView.body
  footer — a computed property

The computed property ran again. The separate view's body did not. A computed property is not a view of its own: it is part of ContentView.body, like a function that body calls, so it runs whenever body does. A separate struct is a boundary. SwiftUI creates a new Footer value, compares it with the old one, finds nothing different, and stops there.

This is the real reason to split a large body into small view types rather than into helper properties. It is not tidiness. Each view type is a point at which SwiftUI can decide that nothing below needs to be looked at. The interview-preparation repository answers "How does splitting a view into smaller views help?" in one line: "A child whose inputs didn't change skips its body — pass the smallest input it needs."

Where this comes from: Senior iOS Interview Preparation (GitHub) · WWDC23: Demystify SwiftUI performance — WWDC23, “Demystify SwiftUI performance”: "Each child view is dependent on the view value that gets produced by its ancestor."

Only the third. After the first tap, and again after the second, the console showed the same two lines:

ContentView.body
  body of “closure changes state”

To skip a child's body, SwiftUI has to be able to tell that the child's inputs are the same as last time. A string can be compared. A closure cannot, in general: Swift has no == for functions. All that can be compared is what the closure is made of — the code it points to, and whatever it captured.

A closure that captures nothing is made of the same thing every time, and that child was left alone. { other += 1 } is different. To change the parent's state it has to capture the parent — self, with its state — and it is built afresh each time the parent's body runs. To SwiftUI it looked like a new input both times, and the child's body ran both times.

How SwiftUI compares closures is not documented, so treat the first two results as observations on iOS 27, not as a contract. The practical rule is safe either way. In a list of hundreds of rows, a row that is handed a closure which touches the parent may have its body run every time the parent's does. Give leaf views the data they show; and when a view updates more often than you expect, ask it why, with Self._printChanges().

Where this comes from: WWDC21: Demystify SwiftUI (2021 — still the reference on identity) · WWDC23: Demystify SwiftUI performance · Senior iOS Interview Preparation (GitHub) — WWDC21, “Demystify SwiftUI”: "SwiftUI will keep around a copy of the value to perform a comparison and know if the view has changed."

At launch, before any tap:

ContentView: @self, @identity, __store, __count changed.
TripRow: @self changed.
TripRow: @self changed.

After a tap on the counter — one line, and no row is mentioned, because no row's body ran:

ContentView: __count changed.

After "Add a night":

ContentView: \TripStore.trips changed.
TripRow: @self changed.

Three kinds of reason are on show. A name with two underscores is a @State property of the view itself. A key path such as \TripStore.trips is a property of an @Observable object that this body read: SwiftUI tracked the read, as withObservationTracking does — on lesson 16 you write that tracking by hand. And @self means the view was handed a different value — here the one row whose trip changed. Vancouver's row was created again too, compared, found equal, and skipped; that is why there is one TripRow line and not two.

@identity is in the very first line only. Apple's own description of the method says it marks "that the identity of the view has changed" — that the storage SwiftUI keeps for the view is being set up for a new instance. At launch that is expected. If you ever see @identity for a view that should simply be updating, something is replacing the view rather than updating it — an if/else, or an .id() that changes — and its state is being thrown away each time. That is lesson 20.

And remember the status of this tool. Apple, at WWDC: "a debugging-only facility that gives a best-effort explanation of why SwiftUI requested a view's body".

Where this comes from: WWDC23: Demystify SwiftUI performance · WWDC21: Demystify SwiftUI (2021 — still the reference on identity) · Senior iOS Interview Preparation (GitHub) — The description of _printChanges is quoted from the documentation comment that ships with the iOS 27 SDK. The interview-preparation repository: "Self._printChanges() tells you WHY body ran".

The console shows

TripCard: 33 bytes
Text:     32 bytes
UIView:   416 bytes
UILabel:  440 bytes

A TripCard is exactly as big as the Trip it holds: an Int, a String, another Int and a Bool make 33 bytes. It lives on the stack, or inline in whatever holds it, and creating one allocates nothing. A UIView object is more than ten times that size before it has done anything; it is allocated on the heap, it is reference-counted, and it brings a CALayer with it.

That difference is what makes SwiftUI's whole approach affordable. Hacking with Swift's suggested answer: "structs are used because they are much simpler and much more efficient than classes", and "SwiftUI is free to recreate your view structs whenever and as often as it wants, so performance needs to be good."

Give the other two reasons as well. A struct has no inherited state: a UIView subclass carries every property of UIView, wanted or not, while a SwiftUI view holds exactly what you declared. And a value cannot be shared and changed behind your back, which is what lets SwiftUI compare an old description with a new one and trust the result.

Where this comes from: Hacking with Swift interview question: Why does SwiftUI use structs for views? · Declaring a custom view — Hacking with Swift rates this question “advanced”. Apple calls a view "a lightweight description of your user interface".

It compiles, with a warning

main actor-isolated property 'body' can not be referenced from a nonisolated context

That is with the settings of a new project. In the Swift 6 language mode the compiler says the same thing, and it is still only a warning: main actor-isolated property 'body' can not be referenced from a nonisolated context

The View protocol is marked @MainActor. Apple's reference says so in its last paragraph: "A type conforming to this protocol inherits @preconcurrency @MainActor isolation from the protocol if the conformance is declared in its original declaration." So a view struct, with its body, its state and every method you add to it, is on the main actor, and body is always evaluated on the main thread. Two consequences: inside a view you never need to dispatch to the main queue to touch its state; and a view's body and methods are not meant to be called from background code.

Why a warning, and not an error? Because of the other word in that sentence: @preconcurrency. Write the same thing with a protocol of your own that is plainly @MainActor, and the compiler refuses:

@MainActor
protocol Screen {
    var title: String { get }
}

struct Home: Screen {
    var title: String {
        "Trips"
    }
}

nonisolated func describe(_ screen: Home) {
    print(screen.title)
}

It does not compile. The compiler reports

main actor-isolated property 'title' can not be referenced from a nonisolated context

Change the first line to @preconcurrency @MainActor, which says that the isolation was added to something that existed before Swift had actors, and the identical code compiles with a warning: main actor-isolated property 'title' can not be referenced from a nonisolated context That is what Apple did for View.

And a date, because the answer changed. Apple, in 2024: "Views in SwiftUI have always been evaluated on the main actor, and the view protocol is now marked with the main actor annotation to reflect that." Before Xcode 16 the annotation was on body alone, so older code — and older answers — are full of @MainActor written by hand on view structs. Apple again: "you can now remove that annotation without any change in behavior."

Where this comes from: View · WWDC24: What’s new in SwiftUI (the View protocol becomes @MainActor) · WWDC25: Explore concurrency in SwiftUI — Apple, View; WWDC24, “What’s new in SwiftUI”. The declaration in the iOS 27 SDK reads @MainActor @preconcurrency public protocol View.

Twice — once for each time the screen came into view:

screen viewed: Seattle
screen left: Seattle
screen viewed: Seattle
screen left: Seattle

onAppear is viewWillAppear, not viewDidLoad. It runs every time the view comes onto the screen: after a push, and again after the next push. (The popular short answer — that onAppear is called "only when the view is shown for the first time" — is not quite right, as the console shows.) For "screen viewed" that is the correct behavior. For "load the data" it means loading again on every visit.

.task is no different in this respect. The same screen with .task { print(…) } in place of onAppear, visited twice, printed:

task started: Seattle
task started: Seattle

There is no exact viewDidLoad, because there is no moment at which a view is loaded and then kept. The nearest things are these. For work that belongs to the time the view is on the screen, .task { … }: Apple describes its lifetime as one "that matches that of the modified view", and cancels it if the view goes away first. For work that should start again only when some input changes, .task(id:). And for work that should happen once for a piece of data, do it in the model that owns the data. A model object lives for as long as you keep it; a view does not.

Where this comes from: Hacking with Swift interview question: What’s the difference between a view’s initializer and onAppear()? · onAppear(perform:) · task(name:priority:file:line:_:) — Apple, onAppear(perform:): "Adds an action to perform before this view appears."

Four times: once at the start, and once more for every tap. These are the three taps:

sorting 4 cities
sorting 4 cities
sorting 4 cities

The sort has nothing to do with the counter. But it is done inside body, and body runs whenever any state that the view reads has changed. Four cities are nothing. Four thousand, sorted again on every keystroke in a search field on the same screen, is a slow app.

Apple's performance session names it: "Make sure to check for expensive string interpolation or operations like data filtering and other work inside of body." The interview-preparation repository gives the one-line version, under "Why must body stay cheap?": "It can run many times — sorting, formatting, or creating objects there repeats every time."

The cures, in order of preference. Keep the data already sorted in the model, so that body only reads it. Or move the counter into a small view of its own, so that its state no longer belongs to the view that does the sorting. Or compute the result once, when its input changes, and store it.

Where this comes from: WWDC23: Demystify SwiftUI performance · Senior iOS Interview Preparation (GitHub) — WWDC23, “Demystify SwiftUI performance”.

No. The button was tapped, the parent's body ran, and the picker was created again with start: 5. The console says so:

QuantityPicker.init with start 1
QuantityPicker.init with start 5

And the screen still says 1:

@State is storage that belongs to the view on the screen, and it is given its initial value once, when that view first appears. Every later QuantityPicker(start:) is a new description of the same view, and SwiftUI keeps the state it already has. The value in init is an initial value, as the name State(initialValue:) says.

It is the classic trap for anyone who thinks of init as set-up, and the interview-preparation repository lists it by name: "Initial value used ONCE. New values from the parent are ignored." If the parent owns the value, the child should not hold a copy in @State: give it a plain let to display, or a @Binding to change. If the child really should start over when the input changes, give it a new identity with .id(start). Both belong to Part 6, which begins after layout.

Where this comes from: Senior iOS Interview Preparation (GitHub) · State() (the macro, Xcode 27) · WWDC21: Demystify SwiftUI (2021 — still the reference on identity) — The interview-preparation repository calls it “the @State initial value trap”. Apple, State(): "Declare state as private to prevent setting it in an initializer, which can conflict with the storage management that SwiftUI provides."

Once. After the tap, the console showed one line, with all three new values in it:

ContentView.body: Vancouver, 3 nights, favorite true

Setting state does not run body. It marks the view as out of date. When the button's action has finished, SwiftUI updates everything that was marked, once. So body never sees the half-way states — Vancouver with five nights, or three nights and no star — and the screen never shows them.

It is the same bargain as setNeedsLayout() in UIKit: you say that something is stale as often as you like, and the work is done once, later. It is also why you do not need to "batch" your changes, and why reading a state property straight after setting it, in the same action, gives you the new value even though the screen has not caught up yet.

Where this comes from: Declaring a custom view · WWDC21: Demystify SwiftUI (2021 — still the reference on identity) — Apple, “Declaring a custom view”: SwiftUI reads body "any time it needs to update the view" — not each time a value is set.

Not at all. The two taps changed the state, and body did not run:

taps is now 1
taps is now 2

The state changed — the action's own print proves it — but nothing on the screen depended on it. While showsCount is false, body never reaches the line that reads taps, so SwiftUI has no reason to ask for body again. Pressing "Show the count" ran body once. From then on body does read taps, and the next tap printed:

taps is now 3
ContentView.body

So the precise answer to "when does body run?" is not "when state changes". It is "when state that body read, the last time it ran, changes". The interview-preparation repository puts the capital letters in the right place: "When state or observed data it READS changes." The same rule holds for @Observable objects, and that is the whole reason they update fewer views than the older ObservableObject did (lesson 18).

Where this comes from: Senior iOS Interview Preparation (GitHub) · WWDC23: Demystify SwiftUI performance · Hacking with Swift interview question: What does the @State property wrapper do? — The interview-preparation repository, “When does SwiftUI re-run a view’s body?”