Swift Concurrency: The Complete Guide

Swift Concurrency revolutionized asynchronous programming on Apple platforms. Introduced with Swift 5.5 in 2021, the model has evolved significantly up to Swift 6.2 which finally simplifies its usage with "Approachable Concurrency". This guide covers everything you need to know, from beginner to expert.

Before Swift 5.5, asynchronous programming relied on callbacks, completion closures, and Grand Central Dispatch (GCD). This model worked but created problems:

Swift Concurrency solves these problems with a model built into the language. The compiler verifies concurrent access safety and async code looks like synchronous code.

The async keyword marks a function that can suspend its execution. The await keyword indicates a potential suspension point.

A crucial point: await never blocks the thread. It frees the thread for other tasks while waiting. This is fundamentally different from a sleep or synchronous wait.

When the runtime encounters an await, it splits your function into "partial tasks". Each segment between two await calls is an execution unit that the runtime can schedule independently.

The runtime can interleave these partial tasks with those of other async functions, optimizing system resource usage.

Task is the fundamental container for asynchronous work. It provides an execution context, manages priorities, and propagates cancellation.

Swift offers several Task types depending on your needs:

The difference between Task and Task.detached is important. A standard Task inherits the caller's context (actor, priority, task-local values). A Task.detached starts in a clean context.

Swift defines several priority levels that influence scheduling:

The runtime can also perform "priority escalation": if a high-priority task awaits a low-priority task, the latter is temporarily promoted.

When you have multiple independent operations, async let executes them in parallel:

Note the difference with sequential execution:

async let creates child tasks that are automatically cancelled if an error occurs or the scope ends.

Swift uses a cooperative cancellation model. When you cancel a Task, it's not killed abruptly. The runtime marks it as cancelled, and it's up to your code to check and react.

Two methods to check for cancellation:

For long-running operations with callbacks, use withTaskCancellationHandler:

async throws functions propagate errors naturally:

With async let, if a parallel task fails, the others are automatically cancelled:

SwiftUI integrates naturally with Swift Concurrency via the .task modifier:

The .task(id:) modifier automatically restarts when the identifier changes:

Swift 6.2 (Xcode 26) introduces major changes to simplify concurrency. The "Improving the approachability of data-race safety" document acknowledges that the model had become too complex.

The most impactful change: you can configure an entire module to run on MainActor by default.

With this setting, all code without explicit annotation runs on MainActor:

In Xcode 26, new projects have this option enabled by default.

Before Swift 6.2, nonisolated async functions automatically jumped to a background thread:

With Swift 6.2, async functions stay on the caller's actor:

This behavior is enabled via the upcoming feature NonisolatedNonsendingByDefault.

If you want a function to truly execute in parallel, Swift 6.2 introduces @concurrent:

This explicit distinction makes code much more readable.

SE-0470 allows restricting a protocol conformance to a specific actor:

Without @MainActor Equatable, the compiler could execute == on any thread, violating the class isolation.

Use async let and TaskGroup rather than Task.detached when possible. Structured concurrency ensures child tasks are automatically cleaned up.

In long loops, periodically check for cancellation:

Use [weak self] to avoid retain cycles:

Don't put everything on MainActor. Reserve it for UI code:

The compiler warns you, but be careful in contexts where await is implicit:

Avoid long operations on MainActor:

Always use Task.sleep for delays:

If you have existing GCD code, here are the equivalences:

Migration example:

Swift Concurrency is a vast topic. Here are the recommended next steps: