Views are value types, not objects
The short version
In SwiftUI, views are value types.
They are:
- structs
- cheap to create
- meant to be recreated frequently
They are not:
- long-lived objects
- identity-based UI elements
- something you mutate directly
This single fact explains a lot of SwiftUI behavior.
What “value type” really means here
A value type:
- has no shared identity
- is defined entirely by its current values
- is cheap to copy
When you write:
Text("Hello")you are not creating a label on screen.
You are creating a description of what the UI should look like right now.
SwiftUI then:
- compares descriptions
- figures out differences
- updates the rendered output
Why this feels strange at first
If you come from UIKit or AppKit, you are used to this mental model:
- Views are objects
- Objects live for a long time
- You mutate them to update the UI
SwiftUI flips this completely:
- Views are temporary
- They are recreated whenever state changes
- Identity comes from data, not from the view instance
This is why things like this do not work:
myView.text = "New value" // ❌There is no stable object to mutate.
Where identity actually lives
In SwiftUI, identity lives in state, not in views.
Examples:
@State@Binding@ObservedObject@EnvironmentObject
Views read state. State drives identity.
That’s why SwiftUI can freely recreate views without breaking your UI.
Why this is a good thing
Because views are value types, SwiftUI gains:
- predictable updates
- cheap recomputation
- easier reasoning about UI
- fewer hidden side effects
Recreating views is not a performance problem — it is the design.
The mental model to keep
A SwiftUI view is a function of state.
If the state changes:
- the function runs again
- a new description is produced
- SwiftUI reconciles the difference
Once this clicks, many SwiftUI “mysteries” disappear.
Context