English for SwiftUI Developers

SwiftUI’s declarative model reframes UI work around state rather than imperative view mutation, and its vocabulary — “view identity,” “single source of truth,” “environment object” — trips up developers coming from UIKit. This guide covers the English used when discussing SwiftUI code with a team.

Key Vocabulary

View identity — how SwiftUI determines whether a view instance is the “same” view across re-renders, which controls whether state is preserved or reset. “That list item loses its animation state on reorder because SwiftUI isn’t preserving view identity — give each row a stable id based on the model, not the array index.”

Single source of truth — the principle that a piece of state should have one authoritative owner, with other views observing or receiving it rather than duplicating it. “We had the same flag stored in two separate @State properties — that’s not a single source of truth, and it’s exactly why they drifted out of sync.”

Property wrapper — an annotation (@State, @Binding, @ObservedObject, @EnvironmentObject) that changes how a property’s storage and observation behaves. “Use @StateObject here, not @ObservedObject — this view is creating the object, so it needs to own its lifecycle, not just observe one passed in.”

Environment object — an object injected into the view hierarchy and accessible to any descendant view without being passed explicitly through every initializer. “Instead of threading the user session through six layers of initializers, inject it once as an environment object at the root.”

View builder — the result builder (@ViewBuilder) that lets SwiftUI compose conditional and multiple views inline inside a declarative body, without explicit array or collection syntax. “This custom container needs to accept arbitrary child content — mark the initializer’s content parameter with @ViewBuilder so callers can write plain SwiftUI syntax.”

Diffing — the process by which SwiftUI compares the old and new view trees to determine the minimal set of changes to apply, rather than redrawing everything. “Wrapping the whole list in one giant view means SwiftUI has to diff the entire thing on every state change — breaking it into smaller subviews narrows the diffing scope.”

Common Phrases

• “Is view identity stable here, or are we resetting state unintentionally on reorder or filter?”
• “Where’s the single source of truth for this value — are we duplicating state across two views?”
• “Should this be @StateObject since this view owns it, or @ObservedObject since it’s passed in?”
• “Is this environment object appropriate here, or is it hiding a dependency that should be explicit?”
• “Is this view too large for efficient diffing — should we split it into smaller subviews?”

Example Sentences

Reviewing a pull request: “This row’s id is the array index, so identity breaks on delete — swap it for the model’s own stable identifier.”

Explaining a design decision: “We hoisted this state up to a shared environment object because three sibling views all needed to read and mutate it in sync.”

Describing an incident: “The animation glitch came from unstable view identity — SwiftUI treated a reordered row as a brand-new view instead of an existing one moving position.”

Professional Tips

• Say “view identity” precisely when debugging state loss on reorder or filter — it’s the SwiftUI-specific root cause reviewers look for first.
• Distinguish “@StateObject” from “@ObservedObject” explicitly in review comments — mixing them up is one of the most common SwiftUI bugs.
• Use “single source of truth” when flagging duplicated state — it’s the standard framing for this class of bug across the whole ecosystem, not just SwiftUI.
• Call out “diffing scope” when a view feels sluggish — it signals you’re thinking about performance in SwiftUI’s own rendering terms.

Practice Exercise

1. Explain in two sentences why using an array index as a list row’s id can break animations.
2. Write a one-sentence code review comment flagging duplicated state across two views.
3. Describe, in your own words, the difference between @StateObject and @ObservedObject.