The Laws of Core Data

Apple's Frameworks teams tend to ship two kinds of APIs -- APIs designed around the needs of first-party apps and APIs designed specifically for third-parties to use. Core Data is characteristic of the second kind of API. It sounds cool in theory, but when you try to use it, it never really seems to do what you want it to. Hence the need to "use an abstraction layer" over an API which is itself an abstraction layer (sqlite) over an abstraction layer (file I/O).

Personal take after quite a few years of experience:<p>ORMs are great for quick and easy prototyping. But in no way I would ever use another ORM in any application again. Simple helpers like Dapper (C#&#x2F;.NET) are fine. But nothing more than that.<p>Learn SQL and handle it yourself. You will be thankful sooner or later.

I’ve been working with iOS since about 2008. I haven’t touched core data for about 10 years...it’s not worth the pain.

I find it incredibly comical that one of the biggest repeated refrains in the parent article is &quot;CoreData is not an ORM!&quot; and yet the comment section is filled w&#x2F; folks talking about how ORMs are bad and how CoreData is a bad ORM.<p>This article is very much worth reading.

Unbelievable timing by Hacker News. I’m building a Swift app with Core Data for the first time and last night I was reading up on how the container&#x2F;context&#x2F;objects fit together :-)

I was on a team that used Core Data and a team that used Realm instead. We had much more success with less headaches by using realm. <a href="https:&#x2F;&#x2F;realm.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;realm.io&#x2F;</a>

They forgot the most important rule of Core Data - just don’t use it!* The amount of problems and nuances it creates is simply not worth the functionality it provides.<p>*If your app manages huge amounts of records on the device, then it might be worth it. But that’s not what many apps use Core Data for. Many apps use it to cache bits of data from the server and other local state. You don’t need a full blown ORM &#x2F; database for this. Instead of wasting your time learning the obtuse Laws of Core Data, model your app state with some nice Codable structs, write it to disk, and then take the afternoon off.

One more law about core data, don&#x27;t edit objects until you&#x27;re ready to commit them, and build a design pattern for other devs to copy that enforces this rule. In theory this is what parent child contexts are supposed to be used for, but the problem is that relationships break once an object is moved into a child context, so you end up with bigger headaches of gradually moving more and more dependent objects into the child context. If you forgo child context and still do edit in place, you&#x27;re constantly playing whack-a-mole with data corruption as you or other devs forget to rollback data when a user cancels out of a flow.

CoreData is a pain in the ass. It feels like it tries to be everything to everyone so it’s nothing to no one.

What is core data?

Good arguments about why to use a graph database for graphs and relational database for records.