Working with data in iOS Apps (What to choose? NSData, CoreData, sqlite, PList, NSUserDefaults)

Question

when I develop an iPhone App (Time Tracker, ToDoList etc) I never know whats the best way to deal with the data. Once I used a plist, next time sqlite or CoreData.

How do you decide whats the best for your project? (Only talking about data management)

For Example if you want to develop:

• Time Tracker App > Is PList your choice?
• RSS Reader App > CoreData?
• Photo App > sqlite?
• EMail Client > ?

For a beginner can you point me roughly to proper directions? (I know it depends a lot on the App and what you like to do with it but any thought will help)

I'm far away from developing complicated apps, they are still pretty simple.

Thanks for help, Marc

Rhinoplasty

if your app is 'database management system' then go for coredata.! But remember it is framework and not a database. – Singsong

Answer 1

You can use these rules of thumb to decide what storage model will work for your app.

• If the data fits in memory entirely and is relatively unstructured, use plist
• If the data fits in memory entirely and has tree-like structure, use XML
• If the data does not fit in memory and has a structure of a graph, and the app does not need extraordinary query capabilities, use Core Data
• If the data does not fit in memory, has a complex structure, or the app benefits from powerful query capabilities provided by relational databases, use sqlite
• If the data must be secret (e.g. a password), use keychain.

Note that these choices often overlap, because multiple storage models will fit the same app. Your final decision depends on your personal preferences - you pick a technology that you understand better.

There was a very good question about sqlite vs. Core Data on Stack Overflow, you may want to read through the answers to that question.

Lapel

Answer 2

My rule of thumb for each of those would be:

• Time Tracker App > Core Data
• RSS Reader App > Core Data
• Photo App > Core Data
• EMail Client > Core Data

Though in each case there would be things you would store on the file system. For instance, the photo app would obviously put the actual photos on the file system. The text of the emails would be on the file system etc. The actual RSS messages might be text files too, but with meta data in Core Data objects.

At some point, you might find that the data you are storing is outgrowing the scalability of Core Data. At that point you would consider moving to SQLite.

The point is that Core Data is so easy to use and so superior to the alleged lighter weight alternatives, why wouldn't you use it?

Tinny