Why NSManagedObjectContext no longer triggers concurrency errors in Swift 6.2? The real change lies in Core Data’s SDK import semantics, not the compiler itself. NSManagedObjectContext is now marked with NS_SWIFT_SENDABLE and NS_SWIFT_NONISOLATED in Xcode 26

Fatbobman

When NSManagedObjectContext stops triggering concurrency errors in Swift 6.2 (Xcode 26), the reason isn't an improved compiler — it's a change in how Core Data's SDK imports the type. In Xcode 26, NSManagedObjectContext's header now carries NS_SWIFT_SENDABLE and NS_SWIFT_NONISOLATED annotations, making it a Sendable type in Swift. The post traces this discovery through a debugging journey: reproducing the error with plain non-Sendable types (which still fail in both Swift 6.1 and 6.2), isolating the behavior to Core Data specifically, comparing SDK headers between Xcode 16 and Xcode 26, and verifying the macros' effect on custom Objective-C classes. The takeaway: when compiler behavior diverges between versions, check whether framework import semantics have changed, not just the compiler. Despite the new Sendable conformance, sharing NSManagedObjectContext across isolation domains in production is still discouraged.

Why Does Passing NSManagedObjectContext Across Isolation Domains No Longer Error in Swift 6.2? The Real Change Isn't in the Compiler

Did Swift 6.2’s Concurrency Analysis Actually Improve?

Finding the Answer in Core Data’s Interface

What Are NS_SWIFT_SENDABLE and NS_SWIFT_NONISOLATED?

Applying These Macros to Our Own Objective-C Classes