SwiftUI performance

The pipeline: invalidate → body → diff → render

When state changes, SwiftUI does four things, and knowing which step costs what is the diagnostic skill:

1. Invalidate the views whose dependencies changed — nothing else.
2. Evaluate body on those views — producing new value-type descriptions.
3. Diff new descriptions against old — attribute by attribute, using identity.
4. Render only actual differences to the screen.

The consequences run in both directions. Body evaluation is designed to be cheap and frequent — a body returning slightly different structs costs almost nothing, because the diff discards no-ops. But that design carries the contract from the very first SwiftUI lesson: body must be cheap. The pipeline amortises many small bodies; it cannot amortise a sort of 20,000 elements inside one.

So SwiftUI performance work is two hunts, in order:

• Too many invalidations — views re-evaluating that had no business being dirty.
• Too much per evaluation — heavy work inside body.

Hunt 1: who is invalidating, and why

The first tool is one line:

var body: some View {
    let _ = Self._printChanges()      // logs WHY this body ran
    …
}

@self means the view's own value changed (a parent passed new data); @identity means it was recreated; a property name means that dependency changed. Sprinkle it on suspicious views, exercise the UI, read the console. For the visual version, the SwiftUI instrument in Instruments shows body-evaluation counts and durations per view type — the "who ran 400 times during one scroll" table.

The classic causes, in the order you should suspect them:

Legacy whole-object invalidation. The Combine-era ObservableObject invalidates every observer on any @Published change — the pre-Observation world. A codebase mid-migration mixes both models; screens still on ObservableObject re-render wholesale. The fix is the migration you already know: @Observable, whose per-property tracking turns most of this class of problem off.

Dependency breadth. Even with Observation, a row that takes the whole model reads more than it needs:

// Broad: this row depends on every property it touches on the model —
// and re-evaluates when any of them change.
struct Row: View {
    let model: FeedModel
    let index: Int
    var body: some View { Text(model.items[index].title) }
}

// Narrow: the row depends on exactly one value.
struct Row: View {
    let title: String
    var body: some View { Text(title) }
}

Passing values, not containers is the single highest-leverage habit: a row taking String cannot be invalidated by anything but that string changing — and as a plain-data view, SwiftUI can skip re-evaluating it entirely when the parent re-renders with equal inputs.

Unstable identity. The lists lesson's rules return as a performance issue: id: \.self on mutating data, or ids minted per render (UUID() in body — a real bug found in real codebases), make the differ see new views every pass — state torn down, animations restarted, rows rebuilt. Identity churn is invisible in code review and glaring in the SwiftUI instrument.

201 bodies per keystroke versus 1 — same screen, same framework, different dependency shapes. On a device this is the difference between a search field that keeps up with typing and one that hiccups; in the SwiftUI instrument it is the difference between a quiet table and Row at the top with four hundred evaluations.

Hunt 2: work that doesn't belong in body

body runs whenever SwiftUI needs it — so anything expensive inside it runs that often too. The offenders and their homes:

The subtlety interviews probe: let sorted = items.sorted { … } in body is invisible at 50 items and a dropped frame at 5,000 — the code was never wrong, the scale changed. The complexity-vs-profiler pairing from the Instruments lesson tells you which lines have that property.

And the container half: lazy means lazy. List and LazyVStack build rows on approach; a plain VStack in a ScrollView builds all of them immediately. A 1,000-row eager stack pays a thousand body evaluations before the first frame. The reflex: scrolling content of meaningful size → List/Lazy*; small fixed groups → plain stacks. Laziness is not free either: wrap three fixed rows in a LazyVStack and you buy per-cell bookkeeping plus an unknown content height — the scroll indicator jumping as real sizes replace estimates — in exchange for deferring zero meaningful work.