Most iOS developers will agree, Core Data is hard. The majority (myself included) will wimp out and go and use SQLite, key-value stores in iCloud or just avoid data persistence all together. But I thought I would finally get over the mental block I had over Core Data and just learn how it works.

I’m far from an expert at this point, I’ve had 2 days to get my head around the basics and so far I’m impressed. Here’s what I’ve learnt, hopefully it may be useful.

• Core Data is NOT an ORM.

Admittedly, it’s pretty close and it functions a lot like an ORM. But technically, it is a object graph management framework. If you expect to behave exactly like an ORM, you’re most likely going to be disappointed. There’s no ActiveRecord-style Post.all method to just yank out all records of a certain class. It differs from an ORM because of its strengths. It is able to deal with potentially huge graphs of related entities with only a limited amount of memory as is often found on mobile devices. (Though less so with the iPhone these days…) It does this by ‘faulting’ data in and out of memory. Let me give you an example: Say we have two entities: Organisation and Person. When retrieving a list of Organisation objects, Core Data will retrieve the list in to memory. It is possible to retrieve the list of People objects in an Organisation even though those people are not actually in memory yet. Core Data ‘faults’ and retrieves the list of objects in the stated relation, loading only what is needed in to memory at any one time. This approach is awesome for low-memory devices.

• Core Data isn’t just an SQLite database

Yes, Core Data does use SQLite as its backing storage and in debug mode, you can see the raw SQL statements performed on the database, but don’t be fooled, this is simply an implementation detail. The schema may change, unlike the Core Data API. Open up the database and take a look; on large object graphs, it may not look as you expect. Core Data saves the data however it thinks is most efficient, it’s not designed for human-readability at the database level.

• XCode does a lot of the hard-work for you

There’s a lot of boilerplate code to set up a Core Data stack. But XCode handles this for you, just tick the ‘Use Core Data’ box in XCode and you won’t need to worry too much about it. It creates a Persistant Object Store, Managed Object Model and all that gubbins in your AppDelegate.m file so you can access it à la:

1
2
3
4
5
6
7

// At the top of your ViewController
#import "AppDelegate.h"

// When the ViewController is initialised...
AppDelegate *appDelegate = [[UIApplication sharedApplication] delegate];
[appDelegate managedObjectContext];
// Assigning your AppDelegate in the first step removes the need for casting.

• Core Data and iCloud don’t appear to play nice, yet

There have been numerous blog posts about how iCloud doesn’t ‘just work’ like Apple promised it would. Developers were hoping for Core Data stores just to be synced across devices without any problem, apparently that hasn’t happened. iOS 7 may answer some of those issues, but we will have to wait and see.

I’m still learning a lot about Core Data and there is much left to learn.