swift-concurrency

First confirm the code is truly UI-bound, then either isolate the caller with @MainActor or wrap the call in await MainActor.run. Avoid applying @MainActor as a blanket fix without justifying main-actor ownership.

Add a new async method alongside the old one, remove the completion parameter, and replace closure calls with await. For delegate or callback APIs, bridge them with AsyncStream or withCheckedContinuation.

Use an actor in async contexts when you need logical isolation of mutable state. Use Mutex (iOS 18+, macOS 15+) for synchronous access, legacy code integration, or fine-grained locking with short critical sections.

Yes, Swift 6 enables strict concurrency checking and complete data-race safety at compile time, enforcing Sendable requirements and isolation checking across async boundaries. Migration should proceed one error category at a time with build and test validation.

NSManagedObject is not Sendable and is bound to its context's queue, so crossing isolation boundaries risks data races. Pass NSManagedObjectID instead, or map the object to a Sendable value type, and never use @unchecked Sendable on managed objects.

Avoid Task.detached unless you have a documented reason, since it drops the caller's isolation and priority. Prefer structured concurrency with async let or task groups, and use Task { @concurrent in } when the synchronous prefix needs no main-actor access.