Question

There might be applications that are not suited for Core Data – image manipulation programs like Photoshop or Gimp for example. But for applications that are suited for Core Data, say Address Book or iCal, what is the criteria to choose Core Data over a custom model?

Answer 1

I recently started a project where I decided to use Core Data for the first time in a real world application. My application is actually version 2.0 of an older app that uses a custom data model, so I spent a lot of time debating this question. Here are some of the things I asked myself.

• The time to learn how Core Data works in a non-trivial application and fixing the little bugs and idiosyncrasies that pop up when you’re learning a new technology. This may include a prototype or two, since you don’t want to jump into using something like Core Data that will be responsible for such as large chunk of your application.

• Whether or not Core Data will solve problems that are hard to address when using a custom data model, for example storing and holding in memory very large sets of data.

• Whether or not you want to share code with a platform where Core Data is not available, for instance Cocoa Touch. Along the same lines, if you want the resulting data files to be compatible without having to build a separate exporter.

• If learning Core Data will help improve yourself as a programmer, whether its making your more attractive to Mac development shops or just for your own use.

• If your data model is simple enough that you don’t really need things like undo manager support or relationships, the areas where core data really shines.

• If you’re using external libraries or other technologies such as Distributed Objects, where you might not want to use NSManagedObject.