SwiftUI Is a Language for Data Flow (Not Layout)

SwiftUI is often presented as a modern way to build layouts.

Stacks instead of constraints.
Modifiers instead of properties.
Declarative instead of imperative.

That framing is understandable - but it quietly sets the wrong expectation.

SwiftUI is not primarily a layout system.
It is a language for expressing data flow.

Once you see it that way, many confusing behaviors stop feeling mysterious and start feeling inevitable.

The expectation SwiftUI quietly breaks

Many developers approach SwiftUI with an assumption carried over from UIKit:

“I describe my views, SwiftUI figures out the layout, and the views stay around.”

At first glance, this seems to work.
Until it doesn’t.

You notice that:

• views are recreated constantly
• body runs far more often than expected
• state changes appear to redraw large portions of the UI
• layout issues feel indirect and hard to reason about

The problem is not SwiftUI.

The problem is the mental model.

Views are descriptions, not UI objects

In UIKit, a view is an object on screen.
It has identity, lifetime, and mutable properties.

In SwiftUI, a view is a temporary value - a description of what the UI should look like right now.

Text("Hello")

This does not mean:

“Create a label and keep it alive.”

It means:

“Given the current state, this is the UI I want to see.”

SwiftUI then:

• evaluates that description
• compares it to the previous one
• updates the rendered output efficiently

The view itself is disposable.
The data is not.

Data flow is the real architecture

Once layout stops being the center of attention, a clearer structure emerges.

SwiftUI is organized around ownership and data flow:

• @State owns local mutable data
• @Binding grants controlled access to that data
• ObservableObject represents shared, long-lived state
• Environment propagates dependencies implicitly

Views do not manage this data.
They observe it.

They are pure functions of state.

Why recomputation is not a performance problem

A common fear sounds like this:

“SwiftUI keeps recomputing my views - isn’t that inefficient?”

Only if you assume views are expensive objects.

They are not.

SwiftUI expects:

• frequent recomputation
• cheap view creation
• minimal logic inside body

Recomposition is not a side effect to avoid.
It is the core mechanism that keeps the UI correct.

Layout is a consequence, not the goal

Layout still matters - but it is downstream.

Stacks, frames, alignment guides, geometry readers - all of these exist to reflect state changes visually.

When data changes:

• views may appear or disappear
• transitions may animate
• layout may adjust

Layout follows data.
Never the other way around.

The mental shift that unlocks SwiftUI

If SwiftUI feels unpredictable, ask yourself:

• Where does this data live?
• Who owns it?
• Who is allowed to mutate it?
• Who only observes it?

Once those answers are clear, SwiftUI becomes calmer.

Less magical.
More mechanical.
And much easier to reason about.

One sentence to remember

SwiftUI is not a system for arranging views.
It is a system for expressing data flow that happens to produce a UI.

Tags: SwiftUI · Architecture · Mental Models