When should I use various storage engines in iOS?

Question

I thought that this would already be considered, but my search did not leave anything meaningful.

I know that there are NSUserDefaults, Core Data, object archiving, raw SQLite, plists and, of course, storage via web servers. What is incomprehensible and somewhat foggy for a beginner is when to use each of these various tools.

The use of web servers and master data is obvious, but what about NSUserDefaults vs plists? Basic data and archiving of objects? A simple breakdown of use cases will really help me understand why there are so many storage options in iOS.

Answer 1

I am trying to write a quick and simple list of common use cases, because, as @rmaddy reports, this answer may fill out a section of the book:

• NSUserDefaults : NSUserDefaults simple user settings, nothing complicated or safe. If your application has a settings page with several radio buttons, you can save the data here.

• Keychain (see SSKeychain for a large shell): used to store sensitive data, such as credentials.

• PLists : used to store large structured data (but not huge): it is a really flexible format and can be used in a lot of scenarios. Here are some examples:

  • Custom Content Store: A simple Geopoint list that will be displayed using a map or list.
  • Provide simple source data to your application: in this case, plist will be included in the NSBundle instead of being generated by the user and populated with user data.
  • Separate the data needed for a specific module of your application from other data. For example, the data needed to create a step-by-step startup guide, where each step is similar to the others, but just needs different data. Hard coding this data will easily populate your code so you can be a better developer and use plists to store and read data.
  • You are writing a library or framework that can somehow be customized by the developer who uses it.

• Object archiving can be useful for serializing more complex objects, maybe full binary data, which you cannot (or which you do not want) to map to simpler structures such as plists.

• Core Data are powerful, can be supported by various persistent repositories (SQLite is just one of them, but you can also select XML files or even write your own format!) And gives the relationship between the elements. It is complex and provides many features useful for development, such as KVO and contexts. You should use it for large data sets from a variety of correlated records that can be created by the user or provided by the server.

• Raw SQLite is useful when you need really fast access to a relational data source (Core Data introduces some overhead), or if you need to support the same SQLite format on multiple platforms (you should never mess with internal SQLite CoreData: it uses it native format, so you can’t just “import” an existing SQLite into CoreData). For example, for the project I was working on, the web service provided me with some large SQLite instead of jsons or xmls: some of these SQLite were imported into CoreData (an operation that may take some time, depending on the size of the source), because I all needed its functions, while other SQLite were read directly for quick access.

• Webserver storage should well be obvious: if you need to store data on the server, this is due to the fact that the device should not be the sole owner of this data. But if you just need to synchronize the same application on different iOS devices (or even with a Mac-ported version of the application), you can also look at iCloud storage.