{"id":39698,"date":"2023-06-12T14:18:18","date_gmt":"2023-06-12T18:18:18","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=39698"},"modified":"2023-09-14T08:22:05","modified_gmt":"2023-09-14T12:22:05","slug":"swiftdata","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2023\/06\/12\/swiftdata\/","title":{"rendered":"SwiftData"},"content":{"rendered":"

Apple<\/a> (Hacker News<\/a>):<\/p>\n

\n

Combining Core Data’s proven persistence technology and Swift’s modern concurrency features, SwiftData enables you to add persistence to your app quickly, with minimal code and no external dependencies. Using modern language features like macros, SwiftData enables you to write code that is fast, efficient, and safe, enabling you to describe the entire model layer (or object graph) for your app. The framework handles storing the underlying model data, and optionally, syncing that data across multiple devices.<\/p>\n<\/blockquote>\n

We’ve been anticipating this for years, and it finally happened. Apple was waiting until it could utilize Swift Concurrency and macros, and I think that was a good decision. As expected<\/a>, it’s more a Core Data wrapper than a complete reimagining. This is making some people unhappy, but I think the underlying Core Data design is still pretty solid. Perhaps over time Apple will reimplement the back end, as they are doing with Foundation. I’d certainly like to see less overhead at the managed object level, and database operations should be able to go a lot faster if they can work directly with Swift’s UTF-8 strings.<\/p>\n

Since it requires Sonoma, and the initial version is completely inadequate for my needs, SwiftData probably won’t show up in my own code for years. But I’m pleased to see that Apple is moving in the same direction as I’ve been doing with my own Core Data code: schemas defined in code, type-safe predicates, a Collection<\/code> for batch processing, and migrations decomposed into stages of lightweight table alterations with interleaved fixups.<\/p>\n

I was excited to see that there were five<\/em> WWDC sessions about SwiftData, but it turns out that they were rather short, repetitive, and lacking in depth. Apple seems to have deliberately avoided comparing it to Core Data and giving us a map of what’s different vs. the same and what’s not supported (yet?). So here are some things that I found notable and some questions that were unanswered:<\/p>\n

Just about everything was renamed. In some cases this makes sense. For example, I never really understood why we had NSEntityDescription<\/code> instead of just NSEntity<\/code>. Now it’s Entity<\/a><\/code>. In other cases, it’s a bit confusing because NSManagedObject<\/code> has become PersistentModel<\/code>, whereas “model” used to mean something completely different that is now called Schema<\/code>. “Transient” was not renamed but its meaning has changed. There’s no more store coordinator and no replacement for some of its functionality.<\/p>\n

The XML and binary store types are gone. I’m guessing that the memory store is now based on SQLite, though I don’t think Apple has said.<\/p>\n

It sounds like Predicate<\/a><\/code> does not yet support everything that NSPredicate<\/code> did, but it’s not clear to me exactly what the differences are or to what extent you can use NSPredicate<\/code> from SwiftData. I guess a lot of questions can probably be answered from the code<\/a>.<\/p>\n

Likewise with various schema features. I didn’t see anything about indexes or validation predicates. Having .unique<\/code> just do an UPSERT<\/code> when there’s a conflict is kind of cool, but what if I want to handle constraint violations in a different way? Composite uniqueness constraints still seem to be handled as arrays of strings. If you want to include components of a composite attribute, I guess you’re supposed to use the mangledName<\/code>?<\/p>\n

How do PersistentIdentifier<\/a><\/code>s work? I don’t see a way to convert it back and forth to NSManagedObjectID<\/code> or URL<\/code>, which seems like a major problem. There also doesn’t seem to be the concept of a temporary identifier. Temporary IDs were a major source of bugs with Core Data, but I don’t see how they could have been eliminated without causing major performance problems. If they are still there but opaque to us, that seems bad.<\/p>\n

PersistentModel<\/a><\/code> seems to be missing a lot of lifecycle hooks and control over faulting and refreshing. I was surprised to see that relationships are handled as arrays instead of as sets, even though presumably they are still sets at the database level. There does not seem to be support for ordered relationships. Built-in support for non-object attribute types is great. For structs and enums, it’s not fully clear to me when they get automatically destructured into composite attributes, when it just uses Codable<\/code> to transform them into a blob of data, and whether I can choose.<\/p>\n

Stuff at the context level is more automatic and gives you less control. Auto-saving that can be turned off is nice. But there doesn’t seem to be a way to set a merge policy between the context and store, and I didn’t see anything about merging changes between contexts. There are also no more parent contexts.<\/p>\n

There’s no ModelStore<\/code> class, just ModelContainer<\/code> and ModelContext<\/code>. I guess containers can still have multiple stores because they support a configurations<\/code> array, but I’m not sure whether you can add to this. There doesn’t seem to be a way to assign the store for a new object, nor to scope a fetch to certain stores.<\/p>\n

Persistent history tracking is enabled by default, but you can seemingly only access the history via Core Data.<\/p>\n

Contexts now have much more convenient APIs for batch enumeration (with mutation checking!) and batch inserts\/deletes\/updates. The batch insert API seems less efficient, though, since you have to give it fully realized Swift dictionaries (no shared keys or provider). There does not seem to be a way to do count or dictionary fetches.<\/p>\n

Lastly, SwiftData was clearly designed to work with Swift Concurrency, but Apple didn’t say much about this. I assume the idea is that the language will prevent you from passing model objects out of their context’s actor—but maybe not<\/a>.<\/p>\n\n

See also:<\/p>\n