In my previous article, I discussed the current reality of Core Data in today’s projects: it hasn’t disappeared, and it still has unique value, but the disconnect between it and modern Swift projects is becoming increasingly apparent. In this article, I’d like to continue down that path and introduce an experimental project of mine: Core Data Evolution (CDE).
It’s not a new framework meant to replace Core Data, nor is it an attempt to drag developers back to old technology. 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?
Core Data turns 21 this year — and it's not dead. But it's starting to feel like a visitor from another era. Concurrency wrapped in perform, model declarations buried in boilerplate, string-based predicates waiting to bite you at runtime. This article isn't telling you to leave. It's asking a harder question: if you're staying, what can actually be done?
When the same concurrency-related code fails to compile in Xcode 16 but builds cleanly in Xcode 26, what’s your first instinct? Mine was that the compiler had gotten smarter — but reality turned out to be more nuanced. This post documents a recent debugging journey: starting from a test failure, tracing all the way down to the Core Data SDK interface, and ultimately discovering that the key change had nothing to do with the Swift compiler itself — it was how NSManagedObjectContext is imported into Swift that had changed.
and more...