Issue 621  August 4th 2023

I’ve struggled to know what to write about SwiftData since its debut a few weeks ago, but Pietro Rea’s recent article inspired me. Take a moment to read it before we continue.

A more Swift-friendly data persistence framework is a very welcome addition to our toolkit, but Pietro is correct when he says:

Core Data’s main problem was not a technical problem. It was a marketing problem!

Setting up a Core Data project isn’t excessively complicated, but it can be intimidating, especially for newcomers to Apple platform development. Many years ago, I delivered Objective-C and iOS development training courses, and Core Data always felt like a step too far for a five-day course where students started with no Objective-C knowledge on day one. The code-first approach of SwiftData feels instantly more approachable, so much so that I might have considered covering it in that same training session. That’s a huge step forward.

But Core Data could also feel a little too much for some tasks, leaving you with decisions to make. “Does this data deserve Core Data, or would an atomically loaded property list file fit the task better?” I also don’t get that feeling anywhere near as much with SwiftData.

But while it’s always fun to get something new, it would be so wasteful to throw away the effort that Apple invested into Core Data over the eight years it has been around, especially when it ties so closely to CloudKit and many other technologies. New code means new bugs and the worst bugs lurk in data persistence code.

So, I was delighted to read this line:

SwiftData uses the proven storage architecture of Core Data, so you can use both in the same app with the same underlying storage.

It’s not entirely clear to me how much of Core Data remains, and it’s still early days to call SwiftData a triumph since it’s still in beta, but Apple may have got it right with SwiftData.

I can’t wait to confidently answer “How should I store data in my app?” with a simple “SwiftData”.

Dave Verwer