Core Data (along with Tiger) has been out in the wild for over a year, now. As a result, most of the whys? and hows? of CD have been answered at great length in mailing lists and updated documentation. A question that still gets asked on a fairly regular basis, though, is when? When should I use Core Data in my application?

The flip answer is, “Whenever you can!” Core Data is an incredibly powerful technology that crosses “Model” off the MVC list of Things Programmers Worry About. Unfortunately, not every program is a good fit with CD, and sometimes trying to wedge an inappropriate app into the CD mold can cause more complexity than it banishes. So how do you know if your app is a good candidate for CD use? Your answers to the following three questions will let you know.

Does my application need to run on versions of OS X prior to 10.4?

The easy one first: Core Data is a part of Tiger. Applications written to take advantage of CD, therefore, must be run on Tiger. If your app needs to target 10.3, 10.2, or any earlier version of OS X, CD isn’t for you. End of story.

Does my application require a specific file format?

My least favorite part of writing a new application is creating the translators needed to serialize my data and write it to a file. The inverse of this process is equally tedious. If your application makes use of Core Data, however, these woes are a thing of the past. CD takes care of saving, loading, and all the implied serialization for you — as long as it’s acceptable for your application to use one of CD’s native file formats.

CD is capable of generating human-readable (if not exactly efficient) XML files, snappy binary files, and even impressive SQLite files completely automagically without writing a single line of code. But if you’re developing a word processor that needs to load and save MS Word .doc files, you’re not going to gain any benefit from this really thrilling feature of CD.

This is not to say you couldn’t use CD at all. CD could still make up your app’s in-memory representation of your model. This would let you take advantage of other CD features like automatic undo and graphical object graph management. But, alas, you would still be stuck serializing your data out to files and back again the old fashioned (manual) way.

Does my application require order from its data?

Imagine you’re writing a paint program. This program may let you draw on many different layers that are composited together to form a final image. You need some sort of collection to hold these layers, but order is very important here. If you have a beautiful sunset on one layer and a log cabin on the layer above it, it wouldn’t do to mix up the order of these items. If you get them out of order and put the sunset on top of the cabin, all you’d see then is the sunset!

In most cases like this, you would store these layers in an array. An array is nice because it not only groups like data together in a container, but also indexes it. Here’s an interesting tidbit that many new to Core Data do not know: CD does not provide any array implementation. CD does have a sense of collections by way of to-many relationships. But those relationships are modeled as NSSets, not NSArrays. As such, objects in your to-many relationship may be returned to you in any order. In our paint program example, if we had a to-many relationship from our Document entity to one-or-more Layer entities, and the Layer entities only contained graphic information, we’d never know which layer went on top.

This is not as bad as it sounds. Some applications don’t require any order of their data (a virus checker doesn’t care what order files are scanned in, only that all files end up scanned). Others don’t need the data to be ordered in the model because the data itself provides order (imagine an app that displays the five most recent entries of an RSS feed. The order is provided by sorting the entries’ time stamp, not through any index). Yet others have indexes built-in to their data (say, a program that keeps track of the employees in a company. Each employee’s ID number acts as its own index).

Even in the paint program example we use above, it would be possible to add an index property to the Layer entity so that the order of the layers is preserved in the relationship. So it’s not impossible to create a paint program that uses CD. But you would have to handle assigning index numbers to each of the entities yourself. And you’d have to order the data manually every time it’s fetched… often, frustratingly, by putting it into an NSArray. CD’s other benefits may outweigh the annoyance of this extra work, but the work will still have to be done.

To CD or not CD, that is the question — and the answer, you can see, varies. CD can be applied to any project. But if the project requires the use of custom file formats, one of the major benefits of CD is negated. Likewise, if the project requires ordered data CD can still be used, but a lot of extra work will have to be done to make up for CD’s lack of ordered arrays. And, of course, if your app needs to be compatible with versions of OS X prior to 10.4, CD is right out. The exact tipping point of when these inconveniences outweigh CD’s benefits is different for each project. One thing is certain: if your answer to all of these questions is “no”, you should do yourself a favor and learn Core Data now. This very second. It really is that amazing!