The situation around agent-assisted software development reminds me of the passage in Code Complete where McConnell discusses the importance of being aware of your location in a given “technology wave.” We are still at the early edge of this AI-driven wave, and we are experiencing many of its symptoms: rapidly changing tools, new workflows without settled conventions, and engineers spending time figuring out the tooling rather than simply using it.

A lot has changed in the last year or so. We have all seen the surge in plausible-looking, agent-generated code. Pull requests have grown much larger and arrive much faster. A 2,000-line change can now be put up for review after a few hours. On top of that, polish is no longer a proxy for code quality. The problems in code are not typos, but unnecessary abstractions or mistaken assumptions made early in the design. The PR author may not have read every line they are putting up for review, never mind carefully reasoning through it as they would hand-written code. The reviewer may be the first human to read the code closely.

Unfortunately, code review has not evolved at the same pace as code generation. Human review is becoming a bottleneck—but that gives us an opportunity to reconsider what code review is actually for.

Even prior to agents, I found a disconnect between what engineers thought the purpose of code review was and what actually ended up being valuable. Teams expect reviews to be about finding defects, but they really serve to facilitate knowledge transfer and allow alternative solutions to be considered (Bacchelli and Bird, 2013). In that context, maybe we are automating the smaller benefit and risking the larger ones. Automated review may already be more effective at catching local or mechanical issues than a hurried human, but it quietly eats away at learning until knowledge transfer goes to zero. After all, if we see a green check on a PR, do we really expect to consistently dedicate time to deeply understand it at the expense of our own work?

What Human Review Is For

The question we ought to ask ourselves in the middle of all this development acceleration is how do we reimagine many things we took for granted… If you ask me, the way we do code review today makes less and less sense, and the same is true for pull requests. — Venkat Venkataramani, VP @ OpenAI

The software development lifecycle is evolving so quickly that predicting its eventual shape is probably ill-advised. But there is no question that PR review needs a redesign. My sense is that much of today’s review process will eventually become infrastructure, much as type systems and CI have offloaded work. I can see engineers being a different kind of QA, one step up stream. Like QA, we are increasingly reviewing work done by another party to ensure it meets certain criteria. In the current environment, and possibly for many years, there are a few principles we can keep in mind.

Below I’ll outline some things that I believe matter in human review including ownership, conceptual integrity, and learning, as well as ideas for structuring the changes so that a person can realistically achieve these goals. To start here are some questions I keep in mind as I review code changes.

Does this duplicate an existing abstraction?

A human who has worked in the codebase for years may recognize where an abstraction already exists. With heavily agent-generated code, that is less likely to be caught. Agent-generated PRs show almost twice the semantic redundancy (the same logic expressed through different code) as human-authored ones (Huang et al., 2026). Reviewers are also more lenient and less likely to question this redundancy. Duplication is one of the cardinal sins in programming, so it’s easy to see how this bloat could lead to issues over time.

If you want a system to have conceptual integrity, then somebody has to be looking at the whole system. — Martin Fowler

Is someone (ideally the author) able to defend the changes?

Agents aren’t yet on the hook for responding to incidents, so we as programmers must be able to debug the changes. Using an agent changes who typed the code, not who owns it. Saying “the agent wrote it” in a postmortem means we delegated too much. If we aren’t confident that we understand the changes, they should not be merged. Questions raised during review may be evidence that a change is not yet understandable enough to merge, so they are important to raise.

Does the change fit well in the codebase?

If we take a rubber-stamp approach to code review, we forfeit the ability to control the conceptual integrity of the codebase. Agents are great at producing many independent and uncoordinated changes. Without human oversight, the codebase can quickly devolve into a patchwork of duplicative and incoherent code. Code review is one of the places where we can course-correct individual changes and keep the system’s design intentional.

I will contend that conceptual integrity is the most important consideration in system design. — Fred Brooks, The Mythical Man-Month

What can the team learn from this change?

The reasoning behind a design is often missing from the final diff. These choices are especially important for junior engineers and new hires to learn from. When engineers are handed only the final output, they have no way to learn how to evaluate tradeoffs and grow their expertise. Deliberately discussing those tradeoffs also prevents others from having to repeat the same decision-making process later.

Are the tests sufficient?

If we are reading and writing less of the code, we need high-quality tests to mitigate the risks. Tests have always been the safety net that lets us make changes without breaking things, and at the scale code can now be changed, they’re even more important. Thankfully, tests are also much easier to write with AI. We should review them as carefully as the production code to make sure the agent isn’t simply maximizing coverage. I still find some tests that feel “tautological”—they simply assert the implementation itself rather than verifying any meaningful behavior (e.g. a test that checks that a constant defined in a method has the value it was assigned). Another common failure is heavily mocked tests that are unable to exercise any real behavior.

With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse. — Michael Feathers, Working Effectively with Legacy Code

Sizing and Scoping Changes

Of course, none of this works if the change is too large to understand.

How can we reduce the size of changes?

Research conducted well before the current generation of coding agents found that defect detection declined as reviews grew beyond roughly 400 lines (Cohen, Best Kept Secrets of Peer Code Review, SmartBear/Cisco). We’re now asking more reviewers to do more than just scan for bugs, so I think 400 lines is still a good threshold to aim for. I exclude whitespace, generated files, comments, and tests from this informal count.

But splitting large features into reviewable chunks has always been a challenge. Feature work doesn’t get done in clean, independently reviewable pieces. Agents actually can help with this problem. We can continue iterating until the work is functionally ready in whatever process we prefer, then ask an agent to help organize it into manageable chunks instead of publishing one large PR with a messy history. There are a few ways to do this.

Atomic Commits

Once the work is done, ask the agent to rewrite the commit history on the feature branch (before anyone has pulled and built off of it) so that each commit focuses on one aspect of the change. For instance, model or API changes could be in one commit, UI behavior in another, and tests alongside the behavior they verify. These can be put up together so the reviewer sees the whole picture while retaining the ability to view each commit in isolation. This optimizes for comprehension by preventing the reviewer from having to scroll back and forth in the code review tool past unrelated changes. It also requires very little effort from the author and lets them keep their own workflow, with just a simple cleanup step added.

The end result is that the commits are grouped conceptually rather than chronologically. Instead of showing what order the changes were made in, they are organized into coherent sets that better explain what is being changed.

Stacked Diffs

If your team or workflow fits better with decomposing changes so that each can actually be reviewed and merged independently, then stacks are an alternative approach. Companies like Uber and Meta have used these for years. GitHub added its own gh stack tooling on July 2026. There are many other offerings available such as Graphite. They all help with managing the branches, but more importantly also with all the relationships between them, rebasing/restacking, and merging. This guide has a good overview of how these work.

Independent PRs

If you can divide a change into entirely independent sets of work that can land in isolation, that can often be the best approach. This may involve making preparatory PRs that refactor existing code to be open to extension (the “O” in SOLID), followed by architectural changes and then the behavioral change itself. The final PR can contain the interesting, unique functionality while the earlier PRs contain the more mechanical changes.

Offloading Cognitive Load

There are also steps beyond organizing the change sets themselves that we can take to help out our coworkers as they try to get a handle on changes we put up for review. The goal should be to reduce the amount of context that the reviewer has to mentally reconstruct in order to understand the change.

Automate the First Pass

Having a standardized team protocol that is followed before asking for human review is helpful for keeping routine issues out of the way. I recommend using a shared set of role-specific agents focused on specific tracks such as concurrency and testing to catch mistakes a general-purpose coding agent may overlook. Paul Hudson hosts some nice ones here. If you have access to multiple families of models for reviews, differences in their training data can mean they find slightly different problems too. I like having all of this run via a single pre-review skill that can be invoked just before pushing changes. Agent review pipelines are a topic in their own right that I will cover in a future post, but sharing a process across the team helps raise the bar for the code and makes our reviews more efficient.

Give Reviewers a Map

PR descriptions can add a lot of value for readers. One of my goals is to transfer the context that I gathered through iterating on the implementation so that each reviewer picking it up from scratch doesn’t have to struggle to recreate it (or worse, skip trying). I like to include a reading guide that explains which files matter, which are mechanical piping, how they fit together, and what order to read them in. Any additional narration of the mental model behind the change can only help the reviewers learn. This shouldn’t just be more generated text, but a short, thoughtful, ideally human-written or edited introduction.

Including other modalities like images and diagrams can also be extremely effective. For UI changes, before-and-after screenshots or recordings communicate the high-level intent immediately, making the details easier to understand. For non-UI changes, simple Mermaid diagrams can be very helpful and can generally be rendered directly. For those unfamiliar, Mermaid is essentially Markdown for diagrams. I like adding flowcharts or decision tables showing how behavior changes across scenarios (e.g. to model online and offline states, errors, or retries). They are almost always much easier to understand than nested conditionals or paragraphs of commentary.

In Closing

AI has made it much cheaper to produce code. It has not made it cheaper to understand a system, preserve its conceptual integrity, or take responsibility when something goes wrong. Who knows whether that will continue to be true forever, but for now the goal is still more useful software—not merely more code.

Let’s look at our single-threaded bank account implementation and see what goes wrong when it is instead accessed concurrently. To keep our focus on the concurrency models rather than the banking domain, we’ll keep it super simple and skip things like depositing and handling currency values. I’m also omitting Swift 6 strict concurrency compliance for the same reasons.

Basic Bank Account Implementation

final class BankAccount {
    private var balance: Int

    init(balance: Int) {
        self.balance = balance
    }

    func withdraw(_ amount: Int) -> Bool {
        guard currentBalance() >= amount else {
            return false
        }

        balance -= amount
        return true
    }

    func currentBalance() -> Int {
        balance
    }
}

Let’s begin by defining the invariants our implementation should maintain.

1. A withdrawal must succeed only when sufficient money is available

2. The balance must never become negative.

And now let’s see if these hold when our bank account is accessed concurrently. Say there are two account owners and they decide to withdraw some money from an ATM at the same time.

For a refresher on async let and TaskGroups check out this article.

Swiftwright

The Fork-Join Pattern in Swift Concurrency

Swift Concurrency gives us two APIs for running work in parallel: async let and TaskGroup. They look quite different at first, but they're both expressions of the same underlying pattern, and I find that understanding that pattern makes the relationship between them much clearer…

Read more

6 months ago · 1 like · 1 comment · John

let account = BankAccount(balance: 100)

async let taskA = account.withdraw(80)
async let taskB = account.withdraw(50)

let results = await [taskA, taskB]

Starting balance: 100

Task A reads starting balance = 100
Task B reads starting balance = 100

Task A writes new balance = 20
Task B writes new balance = 50

Total withdrawn: 130
Ending balance: 50

Because the operations may interleave, one possible execution is shown above, but many different interleavings can land us in a pretty bad state. Here we have violated our invariants and allowed a total of $130 to be withdrawn from an account containing only $100, even though the final balance still appears to be positive.

The issue is that the operations are not actually atomic (i.e. indivisible). Notice that even though balance -= amount looks like one statement in Swift, it is not one indivisible machine operation. It is actually three separate steps: load, decrement, and store. When different threads try to withdraw their execution of the three steps can get interleaved and the state gets corrupted. We need to prevent different threads from modifying the state simultaneously.

To prevent this, we need a synchronization mechanism that makes the critical section effectively atomic again. Swift gives us several different ways to accomplish this: NSLock, Mutex, Serial Dispatch Queues, and Actors. We’ll go through them one by one and dig into the details.

NSLock

We’ll start each section by previewing the full implementation.

import Foundation
final class BankAccount {
    private let lock = NSLock()
    private var balance: Int

    init(balance: Int) {
        self.balance = balance
    }

    func withdraw(_ amount: Int) -> Bool {
        lock.withLock {
            guard balance >= amount else {
                return false
            }

            balance -= amount
            return true
        }
    }

    func currentBalance() -> Int {
        lock.withLock {
            balance
        }
    }
}

Note that the closure-based withLock{} syntax is equivalent to the older style of manually calling lock() and unlock(), often in conjunction with a defer{} block to avoid missing early exits. The closure approach is generally clearer and also prevents us from accidentally forgetting to release the lock.

    func currentBalance() -> Int {
        lock.lock()
        defer { lock.unlock() }
        return balance
    }

The purpose of a lock is to create a region of code that only one thread may execute at a time. In our demo above, we noted that “A withdrawal must succeed only when sufficient money is available.” We can use that to define a critical section of our code that should not overlap and surround it with a lock. We have to be careful that the critical section covers the entire invariant, but no more than necessary. The process a thread will follow is:

1. Acquire the lock

2. Execute the critical section

3. Release the lock

While one thread owns the lock, other threads are blocked and must wait to acquire the lock before entering the protected region. This is called mutual exclusion and is what the term mutex stands for. NSLock is Foundation’s implementation of a traditional mutual exclusion lock.

So, we have successfully protected the balance with a lock and avoided data races. But, there are some weaknesses and nuances to using NSLock that we will examine next.

First, notice that inside our withdraw method I am directly reading the balance property, not using the currentBalance() method. If we ever need to add additional logic to the method, we would need to duplicate it inside withdraw(). Why not just use the method?

guard currentBalance() >= amount else {
  return false
}

Well, that would deadlock at runtime with no warning to the programmer writing it.

When currentBalance() attempts to acquire the lock, it discovers that the current thread already owns it (from inside withdraw()). So it blocks and waits for the lock to be released. However, withdraw() cannot release the lock until currentBalance() finishes executing. Neither can make progress.

A second class of issues relates to the fact that the relationship between the state and the lock exists only in the programmer’s head and the compiler has no visibility into it. This means that correctness must depend on the programmer always correctly understanding when and where locking is needed. Let’s say we later add a method to add interest to the balance.

func applyInterest(_ rate: Double) {
  balance += Int(Double(balance) * rate)
}

We’re back to having data races. The compiler cannot verify that every access is properly synchronized, so correctness depends entirely on programmer discipline.

Overall, NSLock is a manual, low-overhead, widely understood option for making a type thread-safe by acting as a gate allowing only one thread through at a time. Its main weakness is that the gating is not directly tied to the underlying data needing protection. We’ll look at Mutex next and see how it addresses this.

Mutex

import Synchronization
final class BankAccount {
    private let balance: Mutex<Int>

    init(balance: Int) {
        self.balance = Mutex(balance)
    }

    func withdraw(_ amount: Int) -> Bool {
        balance.withLock { balance in
            guard balance >= amount else {
                return false
            }

            balance -= amount
            return true
        }
    }

    func currentBalance() -> Int {
        balance.withLock { $0 }
    }
}

Instead of importing Foundation to access NSLock, we are importing Synchronization to access Mutex. The Synchronization framework was introduced in the 2024 OS releases (iOS 18/macOS 15). As the name suggests, Mutex still provides mutual exclusion and operates very similarly to NSLock.

The improvement is that Mutex puts the state inside the lock. We no longer need to track balance and the lock separately. In fact, there is no independently accessible Int at all and thus no way to modify it and accidentally forget to apply locking.

func currentBalance() -> Int {
  balance
}
Compiler Error: Cannot convert value of type ‘Mutex<Int>’ to expected argument type ‘Int’

The implementation uses Swift’s newer ownership and isolation features (borrowing, sending, etc.) which allows the issues to be surfaced as errors at compile time. The only way to access the value is to temporarily borrow it through withLock(). Because the compiler understands the synchronization guarantees provided by Mutex, BankAccount can also safely conform to Sendable.

Two small notes regarding the syntax. Balance is declared as a let constant to prevent the mutex itself from being replaced, but the balance state it manages is still mutable. Second, withLock takes a closure with a parameter for the value stored inside the mutex which is modified via inout, so we reference it via $0 or a named parameter.

With Mutex we’re able to improve how state is represented and accessed. The data is directly tied to the fact that it must be accessed via a lock rather than being an undocumented convention. But we still have many of the same potential risks — deadlock is still possible and we still have to carefully establish the granularity of the lock to cover only the critical section.

Serial Queue

final class BankAccount {
    private let queue = DispatchQueue(label: “BankAccount”)
    private var balance: Int

    init(balance: Int) {
        self.balance = balance
    }

    func withdraw(_ amount: Int) -> Bool {
        queue.sync {
            guard balance >= amount else {
                return false
            }

            balance -= amount
            return true
        }
    }

    func currentBalance() -> Int {
        queue.sync {
            balance
        }
    }
}

Here we have switched to using a serial queue (unless we add the .concurrent attribute, the queue is serial). This is a completely different model for serializing access compared to the locks we’ve looked at above. Instead of structuring the code to allow a single caller into a critical section we are saying “Every operation touching this state must be submitted to the same ordered executor.” The queue itself becomes the synchronization primitive. Unlike locks, callers never directly coordinate with one another—they simply enqueue work.

The dispatch queue tracks work submitted to it and arranges it so that it always completes in order.

submitted:  A → B → C
executed:   A → B → C

By dispatching via sync we ensure that work does not continue until the closure completes. As with locks, the queue must enclose the full invariant — forgetting to wrap currentBalance() in a sync dispatch would again cause data races. And as with NSLock, nothing prevents a future developer from breaking enforcement like this:

func reset() {
    balance = 0
}

Beyond the mutual exclusion that NSLock and Mutex provide, queues also provide work scheduling. So they are a good fit when work operations need to be received and processed in order.

Actor

actor BankAccount {
    private var balance: Int

    init(balance: Int) {
        self.balance = balance
    }

    func withdraw(_ amount: Int) -> Bool {
        guard currentBalance() >= amount else {
            return false
        }

        balance -= amount
        return true
    }

    func currentBalance() -> Int {
        balance
    }
}

The actor version is the smallest implementation so far. There is no explicit lock or queue logic because the actor declaration establishes an isolation boundary. This isolation means that the actor’s state can only be accessed directly by code running on that actor. So, within BankAccount, we do not need to do any manual synchronization. Code outside the actor interacts with it asynchronously by awaiting actor-isolated methods. It’s worth noting that having the async API cascade outward is not always a desired effect — callers must all either already be in an asynchronous context or create one.

Calls outside the actor:
Task {
  let balance = await account.currentBalance()
  let succeeded = await account.withdraw(80)
}

I’ve covered suspension points and continuations in more detail in this article.

Swiftwright

Why Async/Await Isn’t Just Prettier GCD

When writing asynchronous code using async/await, the most obvious improvements are syntactical ones — being able to read the code top-to-bottom and see the execution order, not dealing with masses of completion handlers or complex error handling, etc…

Read more

6 months ago · 1 like · 1 comment · John

But the key concept here is that await marks a potential suspension point. The actor may already be processing an operation and so the caller may need to suspend until the actor can execute it. We are relying on the compiler to fully enforce isolation rather than relying on convention.

Note that we are able to safely call the currentBalance() method directly without issue. Because these are both synchronous and actor-isolated, this is totally safe. That reasoning changes when an actor method contains await, though. Suppose we need to add a remote authorization before withdrawing:

func withdraw(_ amount: Int) async -> Bool {
    guard currentBalance() >= amount else {
        return false
    }

    await authorize(amount)

    balance -= amount
    return true
}

BankAccount is an actor so this seems safe at first glance. Every await divides the method into independent execution segments.

Segment 1: check balance
await authorization
Segment 2: subtract amount

While the actor is awaiting authorization it is allowed to process another operation. In some ways, this is a welcome ability — the actor can remain productive and complete other work while slow operations wait. But here it means that the balance could be changed by a second operation started while the first withdraw call is suspended waiting on the authorization check to complete. This situation is called reentrancy.

The balance must be checked again after any async operations complete.

func withdraw(_ amount: Int) async -> Bool {
    guard currentBalance() >= amount else {
        return false
    }

    guard await authorize(amount) else {
        return false
    }

    guard currentBalance() >= amount else {
        return false
    }

    balance -= amount
    return true
}

The first balance check is an optimization to avoid an unnecessary authorization; the second is the correctness check. Or, if we wanted to avoid directly checking the balance twice, we could restructure it like this.

func withdraw(_ amount: Int) async -> Bool {
    guard await authorize(amount) else {
        return false
    }

    guard currentBalance() >= amount else {
        return false
    }

    balance -= amount
    return true
}

Actor isolation guarantees exclusive access only while an actor-isolated segment is executing. Isolation does not extend across suspension points. In other words, every await inside an actor is a signal to check any assumptions established before the await and recheck them after resuming.

Actors move synchronization into the language itself so that the compiler can prevent unsynchronized access and eliminate the manual auditing required by locks and queues. But they replace reasoning about lock ownership with reasoning about suspension points. We are freed from data races, but still need to make sure we avoid higher-level logical race conditions due to reentrancy.

Conclusion

So when should we use each?

All four approaches solve similar underlying problems—making a critical section effectively atomic—but they fit best in slightly different situations:

• Actors — Default choice for new asynchronous Swift code. The compiler enforces actor isolation, eliminating unsynchronized access to actor state. The main thing to watch for is reentrancy: every await inside an actor is a point where assumptions may need to be revalidated.

• Mutex — An excellent choice for protecting synchronous shared state on modern OS releases. By putting the protected value inside the mutex, the compiler helps enforce correct access rather than relying entirely on programmer discipline. Like any lock, though, you still need to define the correct critical section and avoid deadlocks.

• NSLock — A solid option when supporting older operating systems or working in existing Foundation-based code. It’s lightweight and widely understood, but the relationship between the lock and the data it protects exists only by convention, so correctness depends on consistently applying the locking discipline.

• Serial Dispatch Queue — Best when the problem is naturally expressed as a sequence of ordered work rather than simply protecting shared state. Queues provide both mutual exclusion and scheduling, making them a great fit when the order of operations matters.

From a performance perspective, these primitives all have different costs, but synchronization overhead is rarely the bottleneck in real applications. In most cases, you’ll get better results by choosing the primitive whose mental model best matches your problem than by optimizing for small differences in synchronization performance.

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.