Views
The tree, and what SwiftUI keeps of it
A view is a description, and body is a recipe for producing more descriptions. Nothing in that
sentence is an object with a lifetime, which is exactly the problem: a framework has to keep
scroll positions, text selections and running animations somewhere, and it cannot keep them in a
struct that will be thrown away before the next frame.
The three chapters here are about how SwiftUI bridges that gap, in the order the gap widens.
Composition over configuration is about the shape of the tree you build. UIKit hands you an object with fifty properties; SwiftUI hands you a small type and expects you to wrap it in another. The chapter is about why that trade is worth taking and where it stops paying.
Identity and lifetime is the important one, and if you read a single chapter of this book, read
that. Identity is how SwiftUI decides that the view it is looking at now is the same view it saw
last frame — which is what decides whether @State survives, whether a change animates or cuts,
and whether a List row is reused or rebuilt.
Modifiers are wrappers follows from both. .padding() does not set a property on anything; it
returns a new view containing the old one. Once that clicks, modifier order stops being a rule to
memorise and becomes something you can derive.
Read them in order. Identity is unreadable without the tree, and modifiers are a puzzle without identity.