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

3 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

3 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.