async/await and structured concurrency

async and await

func fetchUser(id: Int) async throws -> User {
    let (data, _) = try await URLSession.shared.data(from: url)
    return try JSONDecoder().decode(User.self, from: data)
}

• async in the signature: this function may suspend.
• await at the call site: this line is a suspension point.
• Only an async context may await — you cannot call one from an ordinary function without creating a Task. The refusal is physical, not stylistic: suspension means "store my state and give the thread back", and a plain synchronous function has nowhere to store that state — its only way to wait would be blocking the thread, the exact outcome await exists to refuse.

The visual result is the important part: asynchronous code reads top to bottom, like synchronous code, with none of the nesting that callbacks force on you.

Sequential await is sequential

Two awaits in a row run one after the other. If each takes a second, the whole thing takes two.

B does not even start until A is done. Often that is what you want — the second request may need the first result. When it is not, you have two better tools.

async let — start now, collect later

async let user = fetchUser(id: id)
async let settings = fetchSettings(id: id)
let profile = Profile(user: try await user, settings: try await settings)

async let starts the work immediately and gives you a placeholder. The await happens where you use the value. Both requests are in flight at once, so the total is the slower of the two rather than the sum.

Look at the order of the printed lines: B finishes first because it is quicker, even though it was started second. Both were running at the same time.

Task groups — a dynamic number of children

async let is for a fixed, known set of jobs. When the count is dynamic, use a group:

withTaskGroup guarantees that every child finishes before the group returns. You cannot accidentally leak a task that outlives its scope.

Why "structured" is the important word

The tasks created by async let and withTaskGroup are children of the current task, forming a tree. Three properties fall out of that:

1. A parent cannot finish before its children. No orphaned work.
2. Cancelling a parent cancels the whole subtree, automatically.
3. An error from a child propagates to the parent, and cancels its siblings.

With completion handlers you had to build all three by hand, and most codebases did not.

func loadEverything() async throws -> [Item] {
    try await withThrowingTaskGroup(of: Item.self) { group in
        for id in ids {
            group.addTask { try await fetchItem(id) }
        }
        var items: [Item] = []
        for try await item in group {
            items.append(item)
        }
        return items
    }
}

If one fetchItem throws, the others are cancelled and the error surfaces from loadEverything. You wrote no cancellation logic.

Cancellation is cooperative

Cancellation sets a flag; it does not kill anything. Long-running work has to check:

for item in hugeList {
    try Task.checkCancellation()      // throws if cancelled
    process(item)
}

Task.isCancelled is the non-throwing version. Most of Apple's async functions check for you — but note what they throw: Task.sleep throws CancellationError, while URLSession's async methods throw URLError(.cancelled). A catch block that only matches CancellationError silently misses a cancelled network call — a real production trap.

Task { } — the unstructured escape hatch

To call async code from a synchronous context, such as a SwiftUI button action:

Button("Refresh") {
    Task {
        await viewModel.reload()
    }
}

Task { } creates an unstructured task: nothing waits for it, and it is not cancelled with its surroundings. In SwiftUI prefer .task { }, which ties the work to the view's lifetime and cancels it automatically when the view disappears.