What Is Swift Concurrency?

Swift Concurrency is the language-level system introduced in Swift 5.5 for writing concurrent, asynchronous code in a safe, structured, and composable way. It replaces callback-based and completion-handler patterns with async/await, and it introduces a compile-time-enforced model for reasoning about data isolation and thread safety.

But understanding Swift Concurrency as “async/await” is like understanding a building by looking only at its entrance. The deeper structure — Swift actors, isolation domains, the cooperative thread pool, task trees, and the Sendable protocol — is what actually defines the model and separates it from prior approaches to concurrent programming in Objective-C and early Swift.

• Why Swift needed a new concurrency model — the fundamental limitations of GCD and completion handlers at scale
• How async/await transforms asynchronous code into a linear, auditable control flow
• The cooperative thread pool: why Swift Concurrency does not create one thread per task and why that matters for performance
• How the compiler enforces safety guarantees that runtime-only models like GCD could never provide

Core Concepts: Actors, Isolation, Sendable, and Structured Concurrency

Four concepts sit at the center of the Swift Concurrency model. Understanding each individually is necessary. Understanding how they interact is the foundation of writing correct concurrent Swift code.

Static vs Dynamic Isolation: A Critical Distinction

One of the most technically precise sections of this conversation is Matt’s explanation of the distinction between static isolation and dynamic isolation — a distinction that becomes critical when working with protocols, closures, and types that cross module boundaries.

Static isolation is isolation that the compiler can verify at compile time based on type annotations and the declaration context. When you mark a class @MainActor, every method and property on that class is statically isolated to the main actor — the compiler knows this without runtime information and enforces it at every call site.

Dynamic isolation, by contrast, is isolation that must be checked or asserted at runtime. It arises when the isolation of a value cannot be determined from its static type alone — for example, when working with protocol-typed values whose concrete conformances may be actor-isolated, or when using assumeIsolated(_:) and related APIs to assert isolation that the compiler cannot infer.

• Why static isolation is always preferable when possible — and the compiler guarantees it provides that dynamic isolation cannot
• The specific scenarios where dynamic isolation becomes necessary: protocols with actor-isolated conformances, heterogeneous task contexts, and legacy ObjC bridging
• How assumeIsolated(_:), MainActor.assumeIsolated(_:), and #isolation enable safe dynamic isolation assertions
• The relationship between static/dynamic isolation and SE-0434 — and why Matt contributed to that proposal
• Practical heuristics for deciding when to annotate statically versus assert dynamically in a real codebase

Migrating Legacy Code to Swift Concurrency

Most iOS and macOS codebases were not written with Swift Concurrency in mind. They use GCD, completion handlers, Combine, delegates, and notifications — patterns that do not map cleanly to the new model and that generate a substantial volume of isolation warnings the moment you move toward Swift 6 strict checking.

Matt has helped many teams through this process, and his advice is unusually concrete: migration is not a single step, it is a progressive tightening of isolation discipline across the codebase, starting from the edges and working inward.

• The recommended migration strategy: enable SWIFT_STRICT_CONCURRENCY at the targeted level first, then complete, and treat warnings as a learning tool before treating them as blockers
• How to audit completion-handler APIs and decide between wrapping them with withCheckedContinuation versus replacing them entirely
• Handling @MainActor mismatches: the most common source of migration friction in UIKit and AppKit codebases
• When @unchecked Sendable is a legitimate temporary measure versus a permanent code smell
• How to approach third-party dependencies that have not yet adopted Swift Concurrency — and the bridging patterns that contain the isolation contamination

Reasoning About Correctness in Concurrent Systems

Beyond the syntax and the APIs, Swift Concurrency asks something deeper of its practitioners: the ability to reason about the state of a system across multiple concurrent execution contexts. This is a skill that takes time to develop, and Matt is one of the clearest thinkers in the community on how to build it.

• The mental model of isolation domains as a map of ownership: every piece of mutable state has exactly one owner at any point in time
• How actor reentrancy creates non-obvious interleaving points — and why you must treat every await inside an actor as a potential state-change boundary
• The difference between data race freedom (what Swift guarantees) and logical correctness (what you still have to reason about manually)
• How to write actor-isolated code that maintains invariants across suspension points — the discipline that separates robust concurrent code from merely warning-free code
• Using preconditions and assertions to make isolation assumptions explicit and debuggable in production builds

Preparing for Swift 6

With Swift 6, strict concurrency checking moves from opt-in to default. Every Sendable violation, every isolation crossing, and every data-race-prone pattern that currently produces a warning becomes a compile error. For teams that have been deferring concurrency work, Swift 6 migration is not optional — it is the new baseline.

Matt unpacks what Swift 6 actually changes at the language level, how to assess the migration complexity of an existing codebase, and the sequencing that makes the transition manageable rather than catastrophic.

• The exact changes Swift 6 makes to the default compiler behavior — what was a warning and is now an error
• How to assess Swift 6 migration complexity before starting: using the warning count under complete strict checking as a proxy metric
• The modules-first migration strategy: adopt Swift 6 mode at the leaf modules of your dependency graph and work toward the root
• New Swift 6 features that actively reduce migration friction: typed throws, nonisolated(unsafe), and improved global actor inference
• How to set realistic team expectations about migration timelines and avoid the two failure modes: moving too fast and breaking everything, or moving too slowly and accumulating debt

Practical Insights from Real-World Experience

Thirty years of building on Apple platforms gives Matt a perspective that transcends any single language feature. He has seen paradigm shifts come and go — from Objective-C to Swift, from manual memory management to ARC, from threading primitives to GCD — and he brings that long-arc view to Swift Concurrency.

• The patterns from GCD-era code that map cleanly to Swift Concurrency — and the ones that need to be rethought entirely
• Why adopting Swift actors is not just a technical migration but a shift in how you think about module boundaries and API design
• The most common misconceptions that slow teams down during migration — and how to correct them early
• How Matt approaches exploring the edge cases of structured concurrency Swift in his open-source projects and what he has learned from pushing the model to its limits