CoreDataEvolution
This library is designed to simplify and enhance Core Data’s handling of multithreading, drawing inspiration from SwiftData’s
@ModelActorfeature, enabling efficient, safe, and scalable operations.[…]
Custom Executors for Core Data Actors
CoreDataEvolution provides custom executors that ensure all operations on managed objects are performed on the appropriate thread associated with their managed object context. It uses aUnownedJob-based serial executor path compatible with the minimum supported OS versions.@NSModelActor Macro
The@NSModelActormacro simplifies Core Data concurrency, mirroring SwiftData’s@ModelActormacro. It generates the necessary boilerplate code to manage a Core Data stack within an actor, ensuring safe and efficient access to managed objects.NSMainModelActor Macro
NSMainModelActoris the main-thread companion macro for classes. It bindsmodelContexttoviewContextand provides the same convenience access APIs (subscript,withContext) throughNSMainModelActorprotocol extensions.Elegant Actor-based Concurrency
CoreDataEvolution allows you to create actors with custom executors tied to Core Data contexts, ensuring that all operations within the actor are executed serially on the context’s thread.
Previously:
- macOS Tahoe 26 Developer Beta 5
- Elegant Concurrency Operations in Core Data
- @Model for CoreData
- Generating Core Data Swift
Update (2026-03-19): Fatbobman:
More precisely, it’s my own answer to these disconnects: If I still value Core Data’s object graph model, its migration system, and its mature runtime capabilities, can I make it continue to exist in modern Swift projects in a more natural way?
[…]
But in the era of cloud sync, Core Data projects often encounter two other very real needs: how to handle continuously changing transaction histories, and how to monitor iCloud / CloudKit’s operational status.
To that end, I’ve also built two complementary tools: PersistentHistoryTrackingKit and iCloudSyncStatusKit.
Update (2026-06-04): Fatbobman:
The point here is not just syntactic simplicity. More importantly, property reads along the relationship chain can still participate in Observation tracking. The framework knows what the view has read, and therefore what it depends on. Developers do not need to manually split out a series of intermediate views just to preserve reactivity.
With Core Data, however, things become much more cumbersome. If you want to use data along a relationship chain in a single view while still preserving real-time responsiveness to changes in that data, you typically need to split each
NSManagedObjectalong the chain into its ownstruct Viewand hold it with@ObservedObject. Otherwise, changes in some intermediate objects may not be accurately propagated to the final view.[…]
For this reason, I decided to fill this capability gap in CDE: to let
NSManagedObjectprovide property-level observation capabilities similar to SwiftData’sPersistentModel. Most importantly, views can respond directly to changes in the data they read without using@ObservedObject.
