| name | modern-swift |
| description | Use when writing async/await code, enabling strict concurrency, fixing Sendable errors, migrating from completion handlers, managing shared state with actors, or using Task/TaskGroup for concurrency. |
Modern Swift (6.2+)
Swift 6.2 introduces strict compile-time concurrency checking with async/await, actors, and Sendable constraints that prevent data races at compile time instead of runtime. This is the foundation of safe concurrent Swift.
Overview
Modern Swift replaces older concurrency patterns (completion handlers, DispatchQueue, locks) with compiler-enforced safety. The core principle: if it compiles with strict concurrency enabled, it cannot have data races.
Quick Reference
| Need | Use | NOT |
|---|---|---|
| Async operation | async/await |
Completion handlers |
| Main thread work | @MainActor |
DispatchQueue.main |
| Shared mutable state | actor |
Locks, serial queues |
| Parallel tasks | TaskGroup |
DispatchGroup |
| Thread safety | Sendable |
@unchecked everywhere |
Core Workflow
When writing async Swift code:
- Mark async functions with
async, call withawait - Apply
@MainActorto view models and UI-updating code - Use
actorinstead of locks for shared mutable state - Check
Task.isCancelledor callTask.checkCancellation()in loops - Enable strict concurrency in Package.swift for compile-time safety
References
Load these based on what you need:
- Concurrency Essentials — Load when writing new async code or converting completion handlers
- Swift 6 Concurrency — Load when using @concurrent, nonisolated(unsafe), or actor patterns
- Task Groups — Load when running multiple async operations in parallel
- Task Cancellation — Load when implementing long-running or cancellable operations
- Strict Concurrency — Load when enabling Swift 6 strict mode or fixing Sendable errors
- Macros — Load when using or understanding Swift macros like @Observable
- Modern Attributes — Load when migrating legacy code or using @preconcurrency, @backDeployed
- Migration Patterns — Load when modernizing delegate patterns or UIKit views
Common Mistakes
@unchecked Sendableas a quick fix — Using@unchecked Sendableto silence compiler errors means you've opted out of safety. If the error persists after@unchecked, your code has a potential data race. Fix the underlying issue instead.Missing
awaitat call sites — Forgettingawaitwhen calling async functions is a compiler error, but checkingTask.isCancelledin a loop without callingTask.checkCancellation()silently ignores cancellation.Capturing
selfin async blocks withoutweak— Holding a strong reference toselfin a long-running async task prevents deinit. Always use[weak self]in closures or use.taskwhich auto-manages the lifecycle.Not checking task cancellation — Long-running operations should regularly check
Task.isCancelledor callTask.checkCancellation(), otherwise cancellation signals are ignored.Forgetting
@MainActoron UI code and test suites — Main test struct and view models that update@Publishedproperties need@MainActor. Forgetting it silently allows cross-thread mutations. Apply@MainActorto: view models, view structs, main test structs, and any type that touches UI.Actor re-entrancy surprises —
awaitinside an actor method can release the lock temporarily. Another task may modify actor state. Design actor methods assuming state can change betweenawaitpoints.