How do you reason about the SwiftUI view lifecycle?

Direct answer

What a strong answer covers

How it works

A SwiftUI View is a struct that describes what should be on screen; SwiftUI creates and discards these values constantly, so the view body must be cheap and free of side effects. What persists is the state attached to the view’s identity in the tree: @State and @StateObject live as long as the view stays at the same position with the same identity, while @ObservedObject and @Binding refer to state owned elsewhere. Identity comes from structure and explicit id modifiers, and changing it resets state. Side effects belong in .task, .onAppear, and .onChange, with .task cancelling automatically when the view disappears.

Example

A list row that creates its formatter with @State is recreated when its id changes after a sort, which also resets a text field inside it; hoisting the editing state to the parent keyed by item id keeps the text stable. A detail view loads its data in .task(id: itemId) so navigating to a different item cancels the previous load and starts a new one.

Common mistakes

• Doing network calls or heavy computation directly in body.
• Using @ObservedObject for an object the view itself creates, so it is recreated on every parent update.
• Relying on onAppear firing exactly once, which it does not.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.