The Laws of Core Data | Hacker News Reader

The Laws of Core Data

davedelong.com

72 pointsAustin_Conlon38 comments

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).

It’s not just an abstraction layer over SQLite, or any database, for that matter, even though it is even often used and thus thought of as an ORM.

It does have a persistence layer, but it is not it’s persistence layer.

See https://nshipster.com/core-data-libraries-and-utilities/

> Contrary to popular belief, Core Data is not an Object-Relational Mapper, but rather an object graph and persistence framework [...] Using Core Data as an ORM necessarily limits the capabilities of Core Data and muddies its conceptual purity. But for many developers longing for the familiarity of an ORM, this trade-off is a deal at twice the price!

Edit: should have read the post before replying to comments ^^’

Core Data traces its roots over 25 years with NeXT's Enterprise Objects Framework (EOF) [1]:

> Many of the core concepts of EOF re-emerged as part of Core Data, which further abstracts the underlying data formats to allow it to be based on non-SQL stores.

Apple also released CloudKit which synchronizes with FoundationDB’s Record Layer making Core Data an alternative to Google Firebase and Amazon’s GraphQL based AppSync.

It is an object oriented approach to data access which many developers prefer while others dislike. SQLDelight [2] is a YeSQL-like alternative for the anti-ORM and anti-Vendor-Lock-In folks but it relies on Multiplatform Kotlin to support both Apple and Android ecosystems.

Engineering is about managing trade-offs given a set of constraints. Core Data is sometimes a fine choice.

[1] https://en.wikipedia.org/wiki/Enterprise_Objects_Framework

[2] https://github.com/cashapp/sqldelight

That suggests that Apple don’t use CoreData internally but my understanding is that they use it quite heavily – Photos for example.

If anything I would argue it’s the other way round; the API is designed first and foremost for internal clients which creates quite a burden of complexity and nuance for third-party clients to come up to speed.

I think the tough thing for Core Data is that it’s effectively a big caching layer and whilst that brings great performance benefits if you understand how and why it does what it does, it also brings a level of complexity and confusion if you don’t.

Having said that, its API is starting to show its age in this new era of type-safety.

Yeah, they use it a lot. Like a ton internally, even for internal to apple apps.

Personal take after quite a few years of experience:

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#/.NET) are fine. But nothing more than that.

Learn SQL and handle it yourself. You will be thankful sooner or later.

I'm really not sure why this was downvoted. I completely subscribe to this opinion. Been a SQL coder since 1997 (C# since 2003) and had my run in with ORMs in the last decade. There is no way I'd voluntarily use an ORM. I just don't see the benefit.

Finally made an account to respond to this. I completely agree with your take on ORMs and learning SQL.

One thing that people get confused with about CoreData is treating it like an ORM; it is not. CoreData is an object persistence framework more in line with object databases than relational databases. The ability to use SQLite is just an implementation detail. It's like how Datomic can use a SQL db as a datastore however does not present data relationally.

When porting apps back and forth between Android and iOS, the biggest thing I miss on Android is CoreData. CoreData is exceptional at what it does and its a shame that more iOS education doesn't focus more on CoreData.

CoreData is not ORM.

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.

biggest problem with core data (imo) was they never ported the data controllers (nsobjectcontroller, nsarraycontroller, nstreecontroller etc) which makes dealing with core data much easier (to say nothing about the lack of bindings as used in appkit)

Take a look at NSFetchedResultsController, it gives you what you want from NSObjectController and NSArrayController, and there aren't really UI widgets on iOS where NSTreeController is appropriate like there are in AppKit.

There are now, DisclosureGroups & OutlineGroup especially would be places in SwiftUI where a NSTreeController might be useful.

there might not be any native uis in uikit that need nstreecontroller, but ive done custom uis in appkit that utilized nstreecontroller (think of a diagramming ui with groups and child groups) and would love to have been able to use those in uikit too, with pure data bindings....

I find it incredibly comical that one of the biggest repeated refrains in the parent article is "CoreData is not an ORM!" and yet the comment section is filled w/ folks talking about how ORMs are bad and how CoreData is a bad ORM.

This article is very much worth reading.

> CoreData is not an ORM!

Ok; I get that point from you. but the article says it's not a database, and that it is, in fact,

> "Core Data is an “object graph and persistence framework”, which is basically like a fancy kind of object-relational mapping. "

So I'm confused by everything in the article and the comments.

When CoreData first released, forums were full of people using it incorrectly, then complaining that it was buggy. It's good to see nothing has changed.

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/context/objects fit together :-)

Unbelievable!

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. https://realm.io/

I used realm for a project, and don't think I would again. It's been a headache to deal with the dependency every Xcode release. They also refused to support SPM until the last minute.

In hindsight I wish I would have learned Core Data instead.

Isn't there something funky with Realm where you can't have many-to-many relationships out of the box?

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.

*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 / 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't edit objects until you'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'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.

Every bit this.

Are there any other decent alternatives for an iOS app?

You can try https://github.com/groue/GRDB.swift

It's a thin wrapper around SQLite, with convenience APIs for record types, robust support for concurrency, and a focus on GUI apps.

Any other similar tools?

GRDB is perhaps the best solution available with a very good API. Simple to start using and all the power of SQL easily accessible if needed.

Have a look at FMDB: https://github.com/ccgus/fmdb/

I don't know or use it personally. But the developer behind it is very experienced and sells the nice, tried and true image editor Acorn here. https://flyingmeat.com

I used FMDB in a number of iOS apps (although it's been quite a few years back) and it was a pleasure to use. It was simple, well-designed, and with no surprises.

https://dflat.io/

Very different trade-offs. Focusing on separating mutations out and provide change subscription mechanism to facilitate one-way data flow UI design.

We had much more success with Realm: https://docs.mongodb.com/realm/ios

In terms of usability it was lightyears ahead of Core Data, and it actually worked smoothly with multi-threaded apps without breaking down constantly (as had been our experience with Core Data). It was a joy to work with.

What is core data?

Apple’s ORM framework for iOS and Mac

That’s the thing. It isn’t an ORM, even though it’s often used like one

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

Reply on news.ycombinator.com