Why Swift Structured Concurrency Requires Design Discipline

Swift’s structured concurrency model arrived with Swift 5.5 and got sharper in Swift 6. It gives Apple platform engineers a way to write asynchronous code that reads almost like synchronous code. The main pieces are async/await, task groups, child tasks, and actors. They sit alongside older tools like DispatchQueue, OperationQueue, and completion-handler APIs. The pitch is good: fewer data races, clearer cancellation, and a call stack that actually helps you debug. But the model does not enforce good design by itself. Structured concurrency can quietly reward sloppy boundaries and punish teams that treat it as a drop-in replacement for GCD. This article is about the discipline required to use structured concurrency well in production iOS, macOS, watchOS, and tvOS apps.

If you are building a real app with a real team, you have probably already hit the moment where a well-intentioned Task { } block starts to feel like a global side effect. That is the central tension: structured concurrency gives you a hierarchy, but only if you choose to maintain it. The compiler will not stop you from spawning unstructured work from a view controller, a SwiftUI view, or a singleton. It will happily let you mix actor isolation with unstructured task creation until your cancellation behavior becomes impossible to reason about. The fix is not more language features. It is design discipline.

What Structured Concurrency Actually Structures

Structured concurrency is not just a syntax change. It is a model for ownership and lifetime. When you create a task inside a withTaskGroup or an async let binding, that task becomes a child of the current task. The parent task cannot finish until its children finish. Cancellation propagates down the tree. Errors can be collected and handled at a single point. This is a real improvement over fire-and-forget GCD blocks, where cancellation was often a manual boolean check and error handling was an afterthought.

But the structure only exists if you stay inside the structured APIs. The moment you write Task { } or Task.detached { }, you are creating an unstructured task. That task inherits some context—priority, task-local values, actor isolation in some cases—but it is not a child of the current task. It will not be cancelled when the parent is cancelled. It will not keep the parent alive. It is a new root. Sometimes that is exactly what you want. Often it is a bug waiting for the right timing condition.

The Unstructured Task Trap

Consider a view model that loads user data when a screen appears. A common first pass looks like this:

func loadUser() {
    Task {
        let user = try await api.fetchUser()
        self.user = user
    }
}

This works in the happy path. But what happens when the user navigates away before the fetch completes? The view model may be deallocated, but the task keeps running. The API call continues. The result is discarded, or worse, it updates a deallocated object. Cancellation is not automatic. If the API call is expensive, you are wasting battery, network, and server resources. If the result mutates shared state, you may have introduced a race that only appears under slow network conditions.

The disciplined version ties the task to the lifetime of the work. In SwiftUI, that often means using the .task modifier, which automatically cancels the work when the view disappears. In UIKit, it means storing the task and cancelling it in deinit or when the screen is dismissed. In a view model, it means exposing a start() and stop() method, or using an AsyncSequence that the view consumes. The key is that the task’s lifetime is owned by something with a clear lifecycle.

Actors Are Not a Free Pass

Actors are the other half of Swift’s concurrency story. An actor serializes access to its isolated state, which eliminates many data races by construction. But actors do not eliminate all concurrency problems. They introduce new ones: reentrancy, deadlocks, and priority inversions.

Reentrancy is the big one. When an actor method suspends—for example, by awaiting a network call—the actor is free to process other messages. That means the state you checked before the await may have changed by the time the await returns. This is not a bug in Swift. It is a fundamental property of actor isolation. But it requires a different way of thinking about invariants. You cannot assume that a value you read before an await is still valid after it.

Reentrancy in Practice

Imagine an actor that manages a cache of downloaded images:

actor ImageCache {
    private var cache: [URL: UIImage] = [:]
    private var inFlight: [URL: Task<UIImage, Error>] = [:]

    func image(for url: URL) async throws -> UIImage {
        if let cached = cache[url] {
            return cached
        }
        if let existing = inFlight[url] {
            return try await existing.value
        }
        let task = Task {
            try await downloadImage(from: url)
        }
        inFlight[url] = task
        let image = try await task.value
        cache[url] = image
        inFlight[url] = nil
        return image
    }
}

This looks reasonable. But there is a subtle issue. Between the await task.value and the line that sets cache[url] = image, the actor may process another message. If two callers request the same URL at nearly the same time, the second caller will see the inFlight entry and await the same task. That is good. But if a third caller arrives after the task completes but before inFlight[url] = nil runs, it will see a stale inFlight entry and await a task that has already completed. That is not a correctness bug, but it is a wasted suspension. More importantly, if the task throws, the inFlight entry is never cleared, and every subsequent caller will await a failed task forever. The fix is to handle the error path explicitly and to be aware that actor state can change across every await.

This is the kind of edge case that does not show up in a demo. It shows up in production, under load, when a specific image fails to download and the cache is poisoned. The discipline is to treat every await as a point where invariants must be re-established, not assumed.

Cancellation Is a Design Decision

Structured concurrency makes cancellation easier to propagate, but it does not make cancellation automatic. A child task that is cancelled will receive a CancellationError at its next suspension point—if it checks. A long-running synchronous loop will not be interrupted unless it explicitly checks Task.isCancelled or calls Task.checkCancellation(). A network request wrapped in URLSession will be cancelled if the task is cancelled, but only if you use the async URLSession APIs. A custom AsyncSequence may or may not respond to cancellation depending on how it is implemented.

This means cancellation is a design decision you make at every layer of your stack. The API layer must use cancellable transports. The parsing layer must check for cancellation between chunks. The UI layer must decide what to show when a task is cancelled: a loading state, a partial result, or an error. None of this is automatic. The language gives you the tools, but the design is yours.

Designing for Cancellation

A practical approach is to define a cancellation policy for each subsystem. For a networking layer, the policy might be: all requests are cancellable, and cancellation is treated as a normal outcome, not an error. For a database layer, the policy might be: writes are not cancellable once they begin, but reads can be cancelled between batches. For a UI layer, the policy might be: cancellation of a screen’s task hides the loading indicator and preserves any partial data.

These policies should be written down. They should be reviewed in code review. They should be tested with slow network conditions and rapid navigation. The alternative is a codebase where cancellation works sometimes, fails silently other times, and produces bugs that are nearly impossible to reproduce.

Task Groups and Error Handling

Task groups are the structured way to run a dynamic number of concurrent operations. They are powerful, but they also concentrate error handling in a way that can be surprising. When a child task in a group throws, the group’s next() method rethrows that error. The default behavior is to cancel all remaining child tasks and propagate the error. That is usually what you want, but not always.

Consider a search feature that queries multiple backends in parallel. If one backend fails, you might want to show results from the others, not fail the entire search. That requires a different pattern: each child task returns a Result instead of throwing, and the parent collects the results and decides what to do. This is a design choice, not a language feature. The language gives you both options; you have to choose the one that matches your product requirements.

Choosing Between async let and Task Groups

async let is the simplest structured concurrency tool. It is perfect for a fixed number of independent operations. Task groups are for a dynamic number. But the choice is not just about count. async let has a subtle behavior: if you await one binding and it throws, the other bindings are implicitly cancelled. That is usually fine, but it can be surprising if you expected the other operations to continue. Task groups make the cancellation behavior more explicit, but they also require more boilerplate. The discipline is to choose the tool that makes the lifetime and error behavior obvious to the next reader.

Testing Structured Concurrency

Testing asynchronous code has always been harder than testing synchronous code. Structured concurrency helps by making the boundaries explicit, but it also introduces new failure modes. Timing-dependent bugs, cancellation races, and actor reentrancy are all difficult to reproduce in a unit test. The solution is not to avoid testing these paths. It is to design for testability.

One effective pattern is to inject a clock or scheduler into your async code. Instead of calling Task.sleep directly, accept a Clock protocol. In tests, use a manual clock that you can advance deterministically. This turns timing-dependent tests into deterministic ones. Swift’s ContinuousClock and SuspendingClock are useful here, but a custom test clock is often better for precise control.

Another pattern is to test cancellation explicitly. Write a test that starts a task, cancels it, and asserts that the expected cleanup happens. Write a test that cancels a parent task and asserts that child tasks are also cancelled. Write a test that verifies an actor’s state is consistent after a reentrant call. These tests are not glamorous, but they catch the bugs that ship to production.

Swift 6 and Strict Concurrency

Swift 6 turns on strict concurrency checking by default. That means the compiler will enforce actor isolation and sendability much more aggressively. This is a good thing, but it also forces design decisions that were previously optional. You will need to mark types as Sendable, decide which types are actors, and think carefully about which code runs on which executor. This is not a migration you can do mechanically. It requires understanding your data flow and your ownership model.

The teams that have the easiest Swift 6 migration are the ones that already treated concurrency as a design concern. They have clear ownership of tasks, explicit cancellation policies, and actors that encapsulate state with well-defined invariants. The teams that struggle are the ones that sprinkled Task { } everywhere and hoped for the best. The compiler will find every one of those sprinkles and ask you to justify it.

Practical Design Rules

Here are the rules I have found most useful when reviewing structured concurrency code:

• Own every task. If you create a task, something must be responsible for its lifetime. That something should be explicit, not implicit.
• Prefer structured APIs. Use async let, task groups, and .task modifiers before reaching for Task { } or Task.detached.
• Treat every await as a suspension point where state may change. Re-check invariants after every await.
• Define cancellation policies per subsystem. Write them down. Test them.
• Handle errors at the right level. Do not let a single child failure take down a whole operation unless that is the product requirement.
• Test the timing-dependent paths. Use injected clocks and explicit cancellation tests.

These rules are not about writing more code. They are about writing code that behaves predictably when the network is slow, the user navigates quickly, and the backend returns an error. That is the environment where production apps live.

FAQ

What is the difference between structured and unstructured concurrency in Swift?

Structured concurrency uses async let and task groups to create child tasks whose lifetimes are tied to a parent task. The parent cannot finish until its children finish, and cancellation propagates down the tree. Unstructured concurrency uses Task { } or Task.detached { } to create tasks that are not children of the current task. They have independent lifetimes and do not automatically inherit cancellation.

When should I use Task.detached instead of Task { }?

Use Task.detached when you need a task that does not inherit the current task’s priority, task-local values, or actor isolation. This is rare in practice. Most of the time, Task { } is the better choice because it inherits useful context. If you find yourself reaching for Task.detached often, that is a sign that your concurrency design may need review.

How do I avoid actor reentrancy bugs?

The key is to treat every await inside an actor method as a point where the actor’s state may have changed. Do not assume that a value read before an await is still valid after it. Re-check invariants after every suspension point. If a sequence of operations must be atomic, consider whether the actor is the right abstraction, or whether you need to restructure the work so that the suspension happens outside the critical section.

Does structured concurrency replace GCD and OperationQueue?

Not entirely. Structured concurrency is the preferred model for new asynchronous code, but GCD and OperationQueue are still useful for specific cases, such as managing a pool of background work or integrating with legacy APIs. The key is to use the right tool for the job and to be consistent within a subsystem. Mixing models without a clear boundary is a recipe for confusion.

If you are working through a Swift 6 migration or trying to untangle a codebase full of unstructured tasks, the next step is to map your task ownership. Draw a diagram of which objects create tasks, which objects cancel them, and which objects own the results. That diagram will tell you more about your concurrency design than any compiler error ever will.