Apple’s SwiftData framework was announced this year at WWDC and it’s what we’ve all been waiting for. A persistence mechanism from Apple, written entirely in Swift for Swift… kind of. The fact is that it’s still the old CoreData framework under the hood, with a sugary layer of Swift on top. While that bodes well in some senses because CoreData is battle-tested, it also means that we continue to carry with us many of CoreData’s idiosyncrasies, which can be either good or bad depending on where you stand.

Personally, I’ve never been a fan of the CoreData model; it always felt a little dense and difficult to wrap my head around. That means it’s super powerful and convenient for some things (e.g. out-of-the-box CloudKit syncing), it also means that debugging when things go wrong is an arduous task that requires you to build an accurate mental model of how CoreData works.

Sound familiar? It’s the same problem that we’ve had with SwiftUI for a while. I’m a huge SwiftUI fan, and I am a champion for it whenever I get the chance because I believe that declarative UI makes for more scalable and maintainable software. However, I also acknowledge that I only started to become effective as a SwiftUI developer once I grokked it well. Before that I was flailing around, sticking random @State attributes where they didn’t belong, forcing tons of updates with objectWillUpdate.send(), and having no idea what I was doing. It took a lot of failing with the SwiftUI view/data lifecycles before I got good. The question then arises: do I want to sink the same investment into SwiftData?

For me, the answer is no. Not yet, at least. SwiftUI fundamentally changed how iOS apps are built and being on the bleeding edge was worth it for me because I felt like I was skating to where the puck was going. It was a different paradigm. I felt like I was sharpening my skills and challenging myself with a new way of thinking about UI development. It was also super neat to get so much UI with so little code.

SwiftData on the other hand is syntactic sugar, a reality stemming from the fact that CoreData is running the show under the hood. It’s lovely that non-optional database types are now non-optional in code. It’s cool that we no longer need to maintain an .xcdatamodel file alongside our wonky @NSManaged Swift data model types. There are a myriad of other ergonomic benefits to SwiftData. At the end of the day, however, it’s not fundamentally changing how we work with persistence layers. Unfortunately, all that syntactic sugar suffers from some standard v1.0 issues. Take a look at this pile of Feedbacks filed by Paul Hudson and don’t even get me started on how SwiftData decides to store Codable structs.

What I am not saying is that SwiftData is bad. It’s an incredible achievement and the team working on it should be proud. We’ve needed something like this to pair with SwiftUI for years, and it’s wonderful that v1.0 is here. What I am saying is that if you’re not a CoreData pro, SwiftData isn’t worth the investment yet (that’s me). If you are a CoreData pro, you might be affected by SwiftData’s current limitations, and it’s hard to know unless you go digging and try to build something and hit a wall. For these reasons, I’m not adopting SwiftData yet. But I am keeping a close eye on it.