fatbobman（东坡肘子）Mar 4

In Swift 6.2 (Xcode 26.3), why can `NSManagedObjectContext` cross actor isolation?

I dug through the Core Data headers to find the real reason—here it is.
https://fatbobman.com/en/posts/sendable-nsmanagedobjectcontext/

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

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.com
Show threadHelge HeßMar 4
@fatbobman That’s really weird though, isn’t it? I wonder what prompted them to mark the context as Sendable, it’s the exact opposite of that?
Show threadMike ApurinMar 4
@helge @fatbobman The context object itself is explicitly thread-safe, so it should have been Sendable all along. The unsafe part is the objects you get from it, and they are isolated by the perform methods.
I think of it similar to e.g. passing DispatchQueue between threads.
Show threadfatbobman（东坡肘子）
@auramagi @helge At this stage where ModelActor is already available, I do not recommend continuing to rely on context.perform to ensure the thread security of the operation. Unless it is really necessary to use the same context instance in different domains, it is a good choice to pass container and create a new context in their respective domains.
https://github.com/fatbobman/CoreDataEvolution
Mar 4 at 11:42pmWeb
Show threadHelge HeßMar 4
@fatbobman @auramagi Either way ModelContext is explicitly not Sendable, which I think makes conceptual sense.
If a MOC itself is actually threadsafe, that would also come with a significant overhead (as it’s tracking the objects, all those registries would need to be locked).
Show threadHelge HeßMar 5
@fatbobman @auramagi A ModelContext, in combination with the objects, is essentially the representation of the in memory transaction. It’s stateful. I really don’t see how it would make sense to make it Sendable, ever.
(I can imagine it could be possible to transfer ownership of the contexts between isolations, ie sending/borrowing, not Sendable)
Show threadMike ApurinMar 5
@helge @fatbobman It's muddled because MOC is the object that performs queue synchronization and the object that runs queries. The first part is thread-safe, the latter isn't.
SwiftData splits the first part to an actor, so it can be more declarative with sendability.
Show threadMike ApurinMar 5
@fatbobman @helge Admittedly, I stopped looking into Swift Data because it was not able to replicate my CoreData setup, so I'm not as familiar. I'll check out the repo, thanks.