{"id":44227,"date":"2024-07-26T14:10:39","date_gmt":"2024-07-26T18:10:39","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=44227"},"modified":"2024-09-30T09:53:28","modified_gmt":"2024-09-30T13:53:28","slug":"swiftdata-and-core-data-at-wwdc24","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/07\/26\/swiftdata-and-core-data-at-wwdc24\/","title":{"rendered":"SwiftData and Core Data at WWDC24"},"content":{"rendered":"

What’s new in SwiftData<\/a>:<\/p>\n

\n

SwiftData makes it easy to add persistence to your app with its expressive, declarative API. Learn about refinements to SwiftData, including compound uniqueness constraints, faster queries with #Index<\/code>, queries in Xcode previews, and rich predicate expressions. Join us to explore how you can use all of these features to express richer models and improve performance in your app.<\/p>\n

[…]<\/p>\n

You can use the new #Unique<\/code> macro to tell SwiftData which combinations of your model’s properties must always remain unique in the model data. When two model instances share the same unique values, SwiftData will perform an upsert on collision with an existing model!<\/p>\n<\/blockquote>\n

It seems there is still no way to control the merge policy.<\/p>\n\n

\n

New in iOS 18 is the ability to use Foundation’s new #Expression<\/code> macro to build complex predicates easily! Expressions allow for reference values that do not produce true or false but instead allow for arbitrary types.<\/p>\n<\/blockquote>\n\n

Create a custom data store with SwiftData<\/a>:<\/p>\n

Combine the power of SwiftData’s expressive, declarative modeling API with your own persistence backend. Learn how to build a custom data store and explore how to progressively add persistence features in your app.<\/p><\/blockquote>\n\n

Track model changes with SwiftData history<\/a>:<\/p>\n

Reveal the history of your model’s changes with SwiftData! Use the history API to understand when data store changes occurred, and learn how to use this information to build features like remote server sync and out-of-process change handing in your app. We’ll also cover how you can build support for the history API into a custom data store.<\/p><\/blockquote>\n\n

See also: the SwiftData documentation<\/a> and updates<\/a>.<\/p>\n\n

I was not impressed with the introduction of SwiftData last year<\/a>, and this year was also a disappointment. It seems like they are working on the wrong things and not communicating their vision for the future of SwiftData and how it will work with (or supplant) Core Data. It’s not clear whether this is a strategy and execution problem or primarily a communication problem, but it is leaving me unsettled.<\/p>\n\n

Last year, SwiftData was very buggy and incomplete. This year, they didn’t talk about fixing the basics but rather about advanced and somewhat niche features like custom stores and history tracking. Last year, there was no integration between SwiftData and Core Data identifiers<\/a> and predicates. There still seems to be none. The only mention of Core Data was that if you’re using Core Data’s persistent history<\/a> you can now migrate to SwiftData history. There were no Core Data sessions at WWDC 2024.<\/p>\n\n

So it remains unclear whether it’s even planned<\/em> for SwiftData to be able to do the things that Core Data can. Is this going to be like SwiftUI<\/a> where five years later they are still reimplementing features the previous framework has had for decades? It’s also unclear whether Core Data even has a future. Last year was encouraging in that both frameworks got equivalent new features at the same time. This year, Core Data got nothing, even though there’s a long list of outstanding feature requests, limitations, and bugs. Is this year an aberration? Or is Core Data in maintenance mode while they focus on SwiftData? It really does not feel good to have multiple apps and 20 years of code built on a framework that Apple isn’t talking about.<\/p>\n\n

The point of building on system frameworks is that they’re in theory better supported than random open source projects. But now the future is uncertain, and it’s closed-source so that no one else can make the fixes or improvements that Apple won’t. I can’t<\/em> rewrite my Core Data code in SwiftData because it’s so limited. Even if there are major improvements next year, they will be locked to macOS 16 and later, so it will be a long time before I can deploy code that uses them. At least right now, it’s not worth<\/em> rewriting my code for a third-party framework. Core Data isn’t announced dead yet, and many other apps use it, so hopefully it’s safe to assume that Apple won’t let it break too badly. But if I were starting a new app today I would seriously consider whether it makes sense to be on the Apple train<\/a>. There are some interesting alternatives such as GRDB<\/a>, Lighter<\/a>, and Blackbird<\/a>.<\/p>\n\n

Donny Wals<\/a>:<\/p>\n

It feels like Apple wanted to do more with SwiftData but they ran out of time. Surely being able to write your own persistence layer wasn’t the one thing they really wanted to ship, right?<\/p>

There’s so much that developers were hoping for this year but we didn’t get any of it.<\/p>

Makes me wonder whether the plan was to replace Core Data entirely and go from there but they couldn’t get it done so they gave us this instead?<\/p><\/blockquote>\n\n

Gwendal Roué<\/a>:<\/p>\n

I mostly see people hitting walls with SwiftData (limited support for non-optional relationships and ordered relationships, predicates that won’t compile, no dynamic predicate, change reactivity that does not work, etc.) And I’m all but charmed by its mutable model classes anyway. Maybe it would be interesting to have a GRDB store, so that one can workaround SwiftData limitations with a robust database API. But then, why not use the robust API in the first place?<\/p><\/blockquote>\n\n

Donny Wals<\/a>:<\/p>\n

\n

Sadly, none of these limitations are the result of Core Data not supporting them. They’re a result of SwiftData’s interface not exposing these features. So even if you ship a custom persistence layer you’re limited by what SwiftData supports. And that’s not much.<\/p>\n

For now, SwiftData remains a framework that’s only useful for small, simple apps that don’t need much in terms of features.<\/p>\n<\/blockquote>\n\n

Fatbobman<\/a>:<\/p>\n

The latest version of SwiftData was surprisingly impactful. Although it might seem that few features were added on the surface, the substantial underlying adjustments were revolutionary. Considering that SwiftData was only founded a year ago, such changes were particularly unexpected. Stability remains a challenge, as seen in the first test version, which may disappoint many developers who had high expectations for SwiftData. However, after in-depth analysis, I believe there is sound reasoning behind these significant adjustments. The new version of SwiftData has almost achieved decoupling from the Apple ecosystem, and once it adds an independent default storage implementation, it will have all the makings of a cross-platform open-source framework. While this is just my personal hope, given Apple’s increasingly open approach to the community, the potential for this transformation is significant. If realized, the current waiting and effort will undoubtedly be worthwhile.<\/p><\/blockquote>\n\n

Helge Heß<\/a>:<\/p>\n

\n

What they apparently didn’t do is fix the actual issues it had, like missing Observation refreshes 🙃<\/p>\n<\/blockquote>\n\n

dasdom<\/a>:<\/p>\n

\n

Is SwiftData dead already?<\/p>\n<\/blockquote>\n\n

SENTINELITE<\/a>:<\/p>\n

\n

I picked up SwiftData last year for my app, & it’s been an excruciatingly painful experience. Cloud syncing doesn’t always work, duplicate entries, etc.<\/p>\n

Things didn’t really improve this year, although some internal things did, because some bugs have been cleaned up.<\/p>\n

But… I just feel lost. I need the foundation of the app to be working, so I can dive into other APIs (Widgets, shortcuts, etc), but it’s been an uphill battle.<\/p>\n<\/blockquote>\n\n

Helge Heß<\/a>:<\/p>\n

Something disappointing in SwiftData is that it doesn’t make use of the static nature of the macro(s). The macro can’t see the full schema like Lighter does, but it could still statically generate a ton, e.g. a static snapshot struct for the backing data. Or predefined indices for quickly binding the snapshot to the SQLite API (or really any).<\/p>

Instead we get custom backends. Is anyone going to use this, for anything? Maybe they’ll eventually release it as FOSS for server side?<\/p><\/blockquote>\n\n

Helge Heß<\/a>:<\/p>\n

IMO the ability to replace the backend is exactly the wrong direction to go 🤷‍♀️ (for an embedded persistence framework). Specific backends should have specific implementations of the SwiftData API, not yet another layer in between that does abstractions which likely won’t fly. Remember the LDAP EOAdapter…<\/p><\/blockquote>\n\n

SENTINELITE<\/a>:<\/p>\n

Adopting SwiftData’s new History stuff, causes my model(s) to crash, as you can’t query embedded structs. […] I’m THIS close to rewriting the back-end. Gah.<\/p><\/blockquote>\n\n

Jon Duenas<\/a>:<\/p>\n

Yeah, it’s just, credit where credit is due, adding CloudKit to SwiftData “just worked”. With bugs and crashes, sure. But barely any extra effort on the developer’s end to do the actual syncing.<\/p>

I’m actually considering whether I should just move rolling my own backend with something like Firebase or Supabase and make local storage more of a cache than the source of truth.<\/p><\/blockquote>\n\n

Duncan Babbage<\/a>:<\/p>\n

\n

Would love any leads on this: setting [Core Data’s] .fetchBatchSize<\/code> causes entire collection to be immediately traversed [by SwiftUI].<\/p>\n<\/blockquote>\n\n

With Core Data and AppKit there are several possible solutions. If you fetch whole objects, the batching “just works,” so long as you stick to one store and avoid converting<\/a> the NSArray<\/code> to a Swift Array<\/code>. With multiple stores, or to save memory, it’s straightforward to just fetch the sorted IDs and bring the objects into memory as needed.<\/p>\n\n

Previously:<\/p>\n