We know that SwiftUI views are ephemeral value types that can be reconstructed frequently, but just because the body property is reevaluated does not mean that an entire new view with a different identity and new state is created. These two events are easily conflated since they may both involve the same SwiftUI code being executed again, but they have very different consequences. So let’s first understand how to distinguish simple changes to a view’s description from changes to its identity.

One caveat that I feel obligated to add is that SwiftUI's reconciliation rules aren't documented and have shifted across releases. So the description below reflects the current model, but not necessarily a contractual guarantee.

View Descriptions

A description change is a new answer to “what should this view look like now?” A description-level change occurs when SwiftUI reevaluates a view’s body and produces a new description of the interface. The view still occupies the same structural position in the view tree, but some aspect of its rendered output has changed.

struct CounterView: View {
    @State private var count = 0

    var body: some View {
        VStack {
            Text("Count: \(count)")

            Button("Increment") {
                count += 1
            }
        }
    }
}

In the above snippet, changes to count cause body to be recomputed, producing a new description of the interface. But SwiftUI can still reconcile that description against the same structural identity, so the state associated with the counter remains intact.

View Identity

An identity change is a new answer to “is this still the same conceptual view?” Identity is closely tied to structure. When the shape of the produced view tree changes — a conditional branch is taken, an element appears or disappears, a view moves between containers — SwiftUI must determine how elements in the new tree correspond to elements in the previous tree. Not every change qualifies — changing a modifier value usually leaves identity intact, for instance — but when correspondence genuinely breaks, new identities and new lifetimes are established.

if isHighlighted {
    Text(title)
        .font(.headline)
} else {
    Text(title)
        .font(.body)
}

Here, the change is no longer purely descriptive. Each branch of the conditional has its own identity. When isHighlighted flips, SwiftUI tears down the Text from the true branch and creates the Text from the false branch — these are two distinct identities, not one view receiving a new description. That said, toggling back and forth doesn’t spawn endless new identities; it will alternate between two stable ones, each with its own lifetime.

This example is particularly surprising because both branches are just Text(title) with a different font, so it’s tempting to expect SwiftUI to recognize them as the same view and simply update the font. It doesn’t. The if/else is a structural fork, and structure determines identity. Because Text holds no state, the identity change here costs you nothing observable — but the font change won’t animate across the branch boundary, and if either branch held a stateful child view, that state would be discarded on every toggle. (You can collapse this into a single identity by changing it to Text(title).font(isHighlighted ? .headline : .body).)

For a deeper look at structural identity and how it is represented, see this article.

State Storage

One of the reasons the distinction between identity and description matters is that ordinary let and var properties are stored directly on the View struct and are therefore recreated with the view value. @State is different. Although a @State property is declared inside the view, its storage is managed externally by SwiftUI and tied to the view’s identity in the view tree.

As a result, if some upstream event causes CounterView (in the above example) to be recreated, count is not necessarily reinitialized. As long as SwiftUI can reconcile the new description against the same identity, the existing state storage can be looked up and reused.

Performance Implications

This is why recomputing body is usually less consequential. SwiftUI is designed to repeatedly ask views for new descriptions of the interface. As long as those descriptions can be reconciled with the same identity, the lifetime associated with that identity continues, and SwiftUI can preserve the state attached to it.

Identity changes are more significant. When a view moves to a different position, is replaced by a different branch, or otherwise no longer corresponds to the same place in the view tree, SwiftUI may establish a new lifetime. At that point, any state associated with the old identity is not associated with the new view.

In summary, the body property is ephemeral and corresponds to the view’s description, while state corresponds to its identity and is continuous. All the long-lived pieces are stored elsewhere, which allows SwiftUI to cheaply recompute the body frequently.

Structural Identity in SwiftUI

Because views are values and not objects — views are descriptions of UI, not instances of it — SwiftUI needs to be able to efficiently compare them to determine when to update the view tree. Unlike frameworks such as React, which primarily reconcile UI structure at runtime using a virtual DOM, SwiftUI pushes much more structural information into the type system at compile time. Achieving this requires a mechanism capable of assigning concrete static types to deeply nested hierarchies containing different view types and control flow such as if statements.

SwiftUI heavily relies on structural identity — the position and static type information of views in the hierarchy — to determine how updates should be applied efficiently. This means that erasing the type to something like AnyView removes structural type information SwiftUI could otherwise use during diffing and update propagation. It would also force SwiftUI to rely more heavily on dynamic dispatch.

Encoding View Hierarchies with @ViewBuilder

SwiftUI’s solution for encoding the structure of a view is to use a result builder. The content closure of each SwiftUI view is implicitly annotated with one: @ViewBuilder. It transforms the body into a concrete nested generic type at compile time. Let’s look at a simple view definition as an example.

struct ExampleView: View {
    var showImage: Bool

    var body: some View {
        HStack {
            Text("Hello")
            if showImage {
                Image(systemName: "star")
            } else {
                Text("World")
            }
            Button("Tap me") { }
        }
    }
}

The compiler relies on @ViewBuilder to desugar it to look roughly like this.

ViewBuilder.buildBlock(
    Text("Hello"),
    ViewBuilder.buildEither(
        first: Image(systemName: "star")
    ),
    Button("Tap me") { }
)

The else branch would similarly use buildEither(second:).

That yields this fully specified type.

HStack<TupleView<(Text, _ConditionalContent<Image, Text>, Button<Text>)>>

You can see how beautifully this fits into SwiftUI’s declarative style; the type itself is a compile-time map of the hierarchy — every branch of control flow and every container is encoded structurally.

Hiding Complexity with Opaque Return Types

This is only half of the solution, though. If every view were exposed as a highly nested generic type, every place a view was referenced would need to include its fully specified type and cascading updates would be needed for simple changes to a single view in a hierarchy. This would create a very brittle structure. Swift addresses this with another language feature: opaque return types. Opaque return types are sometimes described as the opposite of generics because instead of the caller choosing the type, the implementation chooses it. This lets the type be hidden to callers — hence the word “opaque”. The compiler knows the full concrete type, while callers only know that it conforms to the View protocol.

The Takeaway

SwiftUI’s design works because these features complement each other perfectly: @ViewBuilder preserves the complete structural shape of the hierarchy for the framework and compiler, while some View hides that complexity from API boundaries. The result is a system that remains declarative and ergonomic while still retaining compile-time knowledge about the UI tree. It’s impressive how much complexity this design shifts into the compiler and type system. Understanding that flow gives a much clearer picture of SwiftUI’s architecture and many of its behavioral nuances.

Concurrency vs. parallelism

First, a useful starting distinction around terms (from Rob Pike): concurrency is about structure, parallelism is about execution.

Concurrency is a way of structuring a program so multiple logically independent operations can make progress independently — whether interleaved on one core or executing simultaneously on many.

On the other hand, parallelism is multiple operations physically executing at the same instant on separate hardware (multiple cores, GPUs). It’s a property of how the program runs.

The trouble with callbacks and promises

With those definitions in hand: the question for any concurrent language is how it lets you express that structure. Most languages give you callbacks or futures and promises. In their raw form, callbacks and promises tend to behave like a kind of cross-thread goto: control flow escapes lexical structure, and lifetimes become difficult to reason about locally. You may be familiar with goto's downfall with the advent of structured programming, thanks to some opinion pieces by Dijkstra (pronounced Deek-strah, by the way). This is, not coincidentally, where the "Structured" in Structured Concurrency comes from — it's the same idea of respecting lexical scope applied to a new domain and helps simplify a lot of the pain points of GCD.

If you're curious to explore this more, this article is a great walkthrough, particularly the breakdown of how each of these are semantically equivalent to go statements:

• Registering a callback is semantically equivalent to starting a background thread that (a) blocks until some event occurs, and then (b) runs the callback. (Though obviously the implementation is different.) So in terms of high-level control flow, registering a callback is essentially a go statement.

• Futures and promises are the same too: when you call a function and it returns a promise, that means it’s scheduled the work to happen in the background, and then given you a handle object to join the work later (if you want). In terms of control flow semantics, this is just like spawning a thread. Then you register callbacks on the promise, so see the previous bullet point.

The fork-join pattern

Swift's structured concurrency takes a different approach: a pattern called fork-join. The idea is simple — multiple operations start running concurrently (the fork), and then their results are combined once they all complete (the join). async let and TaskGroup are the two APIs that implement this pattern, and they differ along one key axis: whether the number of operations you want to fork is known at compile time (static width) or determined at runtime (dynamic width).

async let — static width

async let is fork-join for a fixed, known number of operations. If you have a predefined number of operations that always need to be performed together, you simply declare them one after the other. Each async let declaration is itself a fork point — the right-hand side begins executing as a child task the moment you write async let. The join happens when you await the binding:

swift

func loadProfile() async -> Profile {
    async let user = fetchUser()        // fork
    async let posts = fetchPosts()      // fork
    async let avatar = fetchAvatar()    // fork

    return await Profile(               // join
        user: user,
        posts: posts,
        avatar: avatar
    )
}

All three fetches are in flight by the time we reach the return. The await is the join site — it’s where we wait for the children to finish and collect their results. The width here is static: there are exactly three child tasks, hardcoded into the source. You couldn’t write this with a variable number of fetches without restructuring.

TaskGroup — dynamic width

TaskGroup is fork-join for a runtime-determined number of operations. When the count or the work depends on values you only have at runtime, you open a group and add a child task for each unit of work you want to run. Each addTask call is a fork; the join occurs as you iterate over the group's results:

swift

func loadPosts(for ids: [UUID]) async -> [Post] {
    await withTaskGroup(of: Post.self) { group in
        for id in ids {
            group.addTask { await fetchPost(id: id) }   // fork
        }

        var posts: [Post] = []
        for await post in group {                       // join
            posts.append(post)
        }
        return posts
    }
}

The shape is the same — fork some children, join their results — but the count is determined by ids.count at runtime rather than baked into the source. If ids has three elements you get three child tasks; if it has three hundred, you get three hundred.

Conclusion

The static/dynamic distinction is usually the deciding factor on which to use. If you know at the call site exactly which operations you want to run concurrently, use async let — each child gets its own typed binding, and you read the results back by name. If the count or the work depends on runtime data, use TaskGroup, at the cost of homogeneous child result types and a bit more setup boilerplate.

Conceptually, though, they’re much closer than they first appear. Both APIs implement the same fork-join structure: child tasks are forked from a parent task, execute concurrently within that parent’s scope, and are joined before the scope completes. The difference is not in the underlying concurrency model, but in how the number of forks is expressed. Either way, you’re expressing the same idea: fork some work to run concurrently, then join the results when you need them.

But the benefits go much deeper on the performance side.

The GCD Model

When GCD was introduced way back with Snow Leopard in 2009, thread pools were the right answer (or so I’m told haha). When a thread is busy or blocked, GCD simply spawns another thread to pick up later work.

In practice, this leads to two significant problems: an explosion in the number of active threads and a related slowdown from having to hop between them. Remember that devices have a fixed number of actual CPU cores — 6 on recent iPhones — so having to time slice between, say, 20 threads to ensure they can all progress doesn’t give you the performance gain you might imagine.

Each time execution shifts between threads, it must perform a context switch, which is a kernel-level operation involving saving all of the current thread’s state and loading and resuming the new thread. On top of this, pulling in the new state pollutes the CPU’s cache (L1, L2), causing further slowdowns by forcing values to be fetched from slower locations.

Enter Continuations

With async/await (and Swift Concurrency more broadly) these problems are avoided by adopting some prior art from C# (among other sources).

Instead of spawning an unbounded number of new threads, the runtime uses a fixed pool of threads roughly equal to the number of CPU cores. And to avoid the slowdown from context switches, it uses a mechanism known as a continuation.

Continuations are essentially portable stack frames — a snapshot of the function’s state and local variables that can be paused and resumed elsewhere. Instead of blocking a thread (which forces a context switch to keep work flowing), the function suspends by saving its state into a continuation and simply returns. The thread is immediately free to run other work — no kernel involvement, no context switch, no cache wipe. As threads are freed up, they can cheaply pick up any available continuations and continue execution.

A Restaurant Analogy

Hopefully this helps visualize what we’ve been talking about.

GCD: If a waiter (thread) is waiting for food (an API call), they just stand at the window doing nothing. If more orders come in, the manager hires more waiters (thread explosion). Soon the kitchen is too crowded to move (context switching).

Async/Await: When the food isn’t ready, the waiter puts a “post-it note” (continuation) on the counter and goes to help another table. The manager never hires more waiters than there are tables.

The Takeaway

Async/await isn’t just nicer syntax than GCD — it’s a fundamentally different concurrency primitive. The readability is a bonus.