SwiftUI

@State declares mutable view-local state owned by the view; mutating it re-renders the body. A Binding ($state) is a two-way reference letting a child read and write that value without owning it.

onAppear follows the view's structural identity, not a controller lifecycle, and fires each time the view enters the hierarchy. A re-inserted view calls it again; one never inserted never fires. It is not a once-per-screen viewDidAppear.

Start it in .task: it runs when the view appears and its Task is cancelled on disappear. .onAppear is synchronous with no cancellation, so a Task there leaks or re-runs. .task(id:) reloads on change while keeping auto-cancel.

A view observes an ObservableObject by holding it in a @StateObject, @ObservedObject, or @EnvironmentObject. @Published fields re-render subscribed views on change. @StateObject owns it; the other two reference an object owned elsewhere.

A view value is a description SwiftUI reads to build the render tree; the struct is made and discarded constantly with no lifecycle. onAppear/onDisappear fire when the render node enters or leaves the hierarchy, not at struct creation.

Views are lightweight structs — value types holding a description of the UI, not rendered objects, so SwiftUI creates and discards them constantly. some View is an opaque return type — one concrete View. body re-runs when state or inputs change.

A view read an @EnvironmentObject no ancestor injected via .environmentObject(_:). Inject it on the sheet or navigation destination that needs it — those don't inherit the presenter's environment. @Environment differs — a keyed value with a default.

Bind NavigationStack(path: $path) to an array of route values: appending pushes, removing pops, replacing rewrites the stack. navigationDestination(for:) maps each value to a screen. A deep link assigns parsed route values to path, rebuilding the stack at once.

It happens when body mutates observed state while SwiftUI is still computing that body — assigning a @State value during evaluation. Move the mutation out of the render pass into .onAppear, .task, .onChange, or a user action.

@StateObject makes the view own the model — SwiftUI creates it once and keeps it alive across re-renders. @ObservedObject only observes an externally-owned object, so creating it there rebuilds it fresh on every re-render, resetting its state.

Replace the controller with a View holding @State for name and greeting. TextField("Name", text: $name) binds the input, a Button sets the greeting, and if !greeting.isEmpty { Text(greeting) } replaces isHidden. A VStack with padding replaces Auto Layout.

ObservableObject re-renders every observing view whenever any @Published field changes. The @Observable macro (iOS 17+) tracks per-property reads, so a view is invalidated only when a property it read changes. Pair it with @State.

Keying rows by array index ties identity to position, so after a reorder SwiftUI treats slot 0 as the same view and keeps its old state on new data. Give each element a stable Identifiable id so identity follows the data, not the slot.

Make a generic struct storing content: Content (Content: View) and mark its init closure @ViewBuilder content: () -> Content. Store the result and place content in your layout. The attribute lets callers pass several views as one closure.

List and LazyVStack build only the rows near the viewport and reuse them while scrolling, so a huge collection stays cheap. Laziness breaks when rows are erased to AnyView, wrapped in a plain non-lazy VStack, or given an expensive body.

Adopt the @Observable macro so SwiftUI tracks per-property reads and re-renders only what changed. Split the model into smaller observable pieces and put each field in its own subview, making that body the invalidation unit.

Wrap the map in a UIViewRepresentable: makeUIView builds the MKMapView once; updateUIView pushes new state into it. The Coordinator holds its delegate and forwards callbacks — region changes, pin taps — back to SwiftUI via @Binding, guarding the write-back so it doesn't loop.

@ViewBuilder is a result builder that combines the views in body into one composite value — for several children, a TupleView. There's no runtime loop; the compiler synthesizes it. Early SwiftUI had overloads only up to ten children.