Swift 6 Concurrency for iOS Engineers (2026): Strict Mode in Production

Actor isolation: a real coordinator and what serialisation actually buys you

An actor serialises access to its stored properties. Pick an actor when state needs to be coherent across concurrent callers — caches, in-memory database, sync coordinators. Don't pick one for compute that should fan out.

// Real cache used by an image pipeline
actor ImageCache {
    private var entries: [URL: UIImage] = [:]
    private var inflight: [URL: Task<UIImage, Error>] = [:]
    private let maxBytes: Int
    private var currentBytes = 0

    init(maxBytes: Int = 50 * 1024 * 1024) { self.maxBytes = maxBytes }

    func image(for url: URL) async throws -> UIImage {
        if let hit = entries[url] { return hit }

        // Coalesce concurrent requests for the same URL
        if let task = inflight[url] { return try await task.value }

        let task = Task<UIImage, Error> {
            let (data, _) = try await URLSession.shared.data(from: url)
            guard let image = UIImage(data: data) else {
                throw URLError(.cannotDecodeContentData)
            }
            return image
        }
        inflight[url] = task

        do {
            let image = try await task.value
            // Re-entered the actor here — state may have changed during await
            inflight[url] = nil
            entries[url] = image
            currentBytes += image.byteSize
            await evictIfNeeded()
            return image
        } catch {
            inflight[url] = nil
            throw error
        }
    }

    private func evictIfNeeded() {
        while currentBytes > maxBytes, let url = entries.keys.first {
            if let img = entries.removeValue(forKey: url) {
                currentBytes -= img.byteSize
            }
        }
    }
}

private extension UIImage {
    var byteSize: Int {
        Int(size.width * size.height * scale * scale * 4)
    }
}

The non-obvious gotcha: actor reentrancy. Inside the do block above, the await task.value suspends and re-enters the actor. Between suspension and resumption, another caller could have added the same URL. The code handles this by checking entries[url] only at the start; the second-checker pattern is correct because the worst case is a transient duplicate decode, not a corrupted cache.

SE-0306 (Concurrency: github.com/swiftlang/swift-evolution/blob/main/proposals/0306-actors.md) defines actor semantics, including reentrancy. WWDC22 'Eliminate data races using Swift Concurrency' (developer.apple.com/videos/play/wwdc2022/110351) at 19:00 walks the reentrancy diagram.

@MainActor and the Capture-of-self diagnostic

The most common Swift 6 error in production migration is Capture of 'self' with non-sendable type 'X' in a `@Sendable` closure. The compiler emits this when a Task captures self and self isn't Sendable.

// FAILS in Swift 6 strict mode
@MainActor
final class FeedViewModel {
    var items: [Post] = []
    private let api: APIClient  // not Sendable

    func reload() {
        Task {
            // ❌ Capture of 'self' with non-sendable type 'FeedViewModel'
            let posts = try await api.fetch()
            self.items = posts
        }
    }
}

// FIX 1 — annotate self's class @MainActor (already done above)
//          AND mark the Task as @MainActor explicitly so the compiler knows
//          self stays main-isolated
@MainActor
final class FeedViewModel {
    var items: [Post] = []
    private let api: APIClient

    func reload() {
        Task { @MainActor in
            let posts = try await api.fetch()
            self.items = posts
        }
    }
}

// FIX 2 — for non-MainActor classes, conform to Sendable explicitly
final class APIClient: Sendable {
    let baseURL: URL  // immutable, Sendable type
    init(baseURL: URL) { self.baseURL = baseURL }
}

// FIX 3 — if you genuinely need shared mutable state without an actor,
//          @unchecked Sendable + manual lock. Last resort.
final class CounterCache: @unchecked Sendable {
    private var count = 0
    private let lock = NSLock()
    func increment() {
        lock.lock(); defer { lock.unlock() }
        count += 1
    }
}

The thing senior engineers learn the hard way: Task { @MainActor in ... } is not the same as await MainActor.run { ... }. The first creates a new top-level task on the main actor; the second is a direct hop on the current task. Inside an already-MainActor method, both produce identical behaviour, but if you call from a non-isolated context, only MainActor.run guarantees ordering with the surrounding code.

Sendable: making your domain types cross actors

Sendable is the type-system gate for cross-actor data movement. Three patterns get you 95% of the way there:

// 1. Value types with Sendable members are auto-Sendable
struct Post: Sendable {
    let id: UUID
    let title: String
    let createdAt: Date
    let tags: [String]
}

// 2. Final classes with immutable Sendable storage
final class Author: Sendable {
    let id: UUID
    let name: String
    let joinedAt: Date
    init(id: UUID, name: String, joinedAt: Date) {
        self.id = id; self.name = name; self.joinedAt = joinedAt
    }
}

// 3. Actor types are implicitly Sendable
actor RateLimiter { /* ... */ }

// THE DIAGNOSTIC YOU'LL SEE
// 'Sending main-actor-isolated value of type X to nonisolated context'
// Means: you're handing a non-Sendable value across an isolation boundary.
//
// The fix in Swift 6 with SE-0414 'Region-based Isolation':
// the compiler proves the value is uniquely owned at the call site.
// You write the same code; if it's safe, it now compiles.

// preconcurrency import for legacy modules that haven't adopted Sendable
@preconcurrency import LegacyKit  // suppresses Sendable diagnostics from this module

SE-0414 (Region-based Isolation, github.com/swiftlang/swift-evolution/blob/main/proposals/0414-region-based-isolation.md) is what made strict mode tractable in real codebases — without it, every transient value passing between actors needed Sendable conformance, which is impossible for class types from third-party frameworks. WWDC24 'Consume noncopyable types in Swift' covers the related ownership concepts.

Migrating completion handlers to async/await

Most production iOS codebases in 2026 still have completion-handler APIs in legacy modules. The bridging pattern uses withCheckedContinuation (or withCheckedThrowingContinuation for throwing variants):

// Legacy — completion-handler API
func fetchUser(
    id: String,
    completion: @escaping (Result<User, Error>) -> Void
) { /* ... */ }

// Bridge — async wrapper. Resume MUST be called exactly once.
func fetchUser(id: String) async throws -> User {
    try await withCheckedThrowingContinuation { continuation in
        fetchUser(id: id) { result in
            switch result {
            case .success(let user): continuation.resume(returning: user)
            case .failure(let error): continuation.resume(throwing: error)
            }
        }
    }
}

// SE-0297 generated equivalent — the compiler can synthesise this when the
// completion handler is the last parameter and matches the Result-or-throws
// shape. Add @available + ObjC selector for backward compat:
// func fetchUser(id: String) async throws -> User

// Cancellation — propagate via Task.checkCancellation()
func fetchAll(ids: [String]) async throws -> [User] {
    try await withThrowingTaskGroup(of: User.self) { group in
        for id in ids {
            group.addTask {
                try Task.checkCancellation()
                return try await fetchUser(id: id)
            }
        }
        var users: [User] = []
        for try await user in group { users.append(user) }
        return users
    }
}

The trap: withCheckedContinuation requires the continuation be resumed exactly once. Resuming twice traps in debug, leaks in release; never resuming hangs the calling task forever. SE-0300 (Continuations, github.com/swiftlang/swift-evolution/blob/main/proposals/0300-continuation.md) defines the contract.

The SE proposals that ground the model

The full proposal list lives at swift.org/swift-evolution. WWDC24 'Migrate your app to Swift 6' (developer.apple.com/videos/play/wwdc2024/10169) at 7:30 walks through enabling strict mode incrementally per target.