What are the factors to decide between using Core Data versus rolling out a custom model?

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?

From stackoverflow

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

• 1. Are you, for whatever reason, targeting a Mac OS X version before 10.4 as your minimum requirement? If so, no Core Data for you.
  2. Are you going to allow the user to manually order things in a list? If so, no Core Data for you—it doesn't allow ordered relationships. (Supposedly you can create a numeric “sequence” property that you can order by, but keeping that consistent sounds like a tremendous hassle.)
  3. Are you going to be working with a specific file format as your native format? (For example, TextEdit's native format is RTF.) If not, you won't be using Core Data for on-disk storage, so you may not want to use it at all. (You could, but I'm not sure there are enough other reasons.)
  Akbar ibrahim : I am not sure I understood the 3rd point correctly. I shouldn't be using Core Data if I have a native file format, correct?

  Peter Hosey : It's one point against it, yes. One reason *to* use Core Data is that it handles on-disk storage for you, so you don't need to make up a file format; the inverse of that is that if you already have a file format, you don't need Core Data to do it for you. But you may have other reasons to use it.