data-flow

SwiftUI Data Flow

Nearly every confusing SwiftUI bug — state that resets, animations that crossfade instead of move, lists that flash, bodies that run constantly — traces to identity, lifetime, or dependencies. This is Apple's own mental model (the Demystify sessions + Data Essentials + Observation), current through the WWDC26 @State macro.

When This Skill Activates

• "@State resets when…" / state loses its value on a condition change
• Views re-render too often; animations crossfade when they should move
• Lists flashing, rows reordering wrongly, ForEach misbehaving
• Choosing between @State, @Binding, @Bindable, @Environment, plain property
• Debugging with Self._printChanges(); concurrency warnings in view code

Identity: the root concept

SwiftUI sees three things: identity, lifetime, dependencies. Views with the same identity are "different states of the same conceptual UI element"; distinct identities are distinct views.

• Structural identity = type + position in the hierarchy. An if/else creates two identities (_ConditionalContent) — flipping the branch destroys/recreates the view: state resets, transitions crossfade instead of animating.

• Explicit identity = id: in ForEach or .id(_:) (also the target for ScrollViewReader.scrollTo). Changing an explicit id is a new identity — new lifetime, fresh state. (That's the .id(item.id) force-refresh trick — use it knowingly.)

• The inert-modifier rule (the most under-used fix): prefer one view whose modifiers vary over branching —

  // ❌ two identities; state resets, transition crossfades
  if expired { content.opacity(0.3) } else { content }
  // ✅ one identity; cheap, pruned when inert
  content.opacity(expired ? 0.3 : 1.0)
  

  Inert values (opacity 1, padding 0) cost nothing. "By default, try to preserve identity."

• Conditionally include a view inside a stack rather than conditionally wrapping the stack.

Lifetime: state is tied to identity