When Should I Use the Various Storage Mechanisms in iOS

When should I use the various storage mechanisms in iOS?

I try to write a quick and simple list of common use cases, because as @rmaddy says this answer could fill a book chapter:

• NSUserDefaults: stores simple user preferences, nothing too complex or secure. If your app has a setting page with a few switches, you could save the data here.

• Keychain (see SSKeychain for a great wrapper): used to store sensitive data, like credentials.

• PLists: used to store larger structured data (but not huge): it is a really flexible format and can be used in a great number of scenarios. Some examples are:

  • User generated content storage: a simple list of Geopoint that will be shown by a map or list.
  • Provide simple initial data to your app: in this case the plist will be included in the NSBundle, instead of being generated by user and filled by user data.
  • Separate the data needed for a
    particular module of your application from other data. For example,
    the data needed to build a step-by-step startup tutorial, where each step is similar to the others but just needs different data. Hard-coding this data would easily fill your code, so you could be a better developer and use plists to store the data and read from them instead.
  • You are writing a library or framework that could be configured in some
    way by the developer that uses it.

• Object archiving could be useful to serialize more complex objects, maybe full of binary data, that can't (or that you don't want to) be mapped on simpler structures like plists.

• Core Data is powerful, can be backed by different persistent stores (SQLite is just one of them, but you can also choose XML files or you can even write your own format!), and gives relationships between elements. It is complex and provides many features useful for the development, like KVO and contexts. You should use it for large data sets of many correlated records, that could be user generated or provided by a server.

• Raw SQLite is useful when you need really, really fast access to a relational
  data source (Core Data introduces some overhead), or if you need to support the same SQLite format across multiple platforms (you should never mess with CoreData inner SQLite: it uses its own format, so you can't just "import" an existing SQLite in CoreData). For example, for a project I worked for, a webservice provided me some large SQLite instead of jsons or xmls: some of this SQLite were imported to CoreData (operation that could take a while, depending on the source size), because I needed all the features of it, while other SQLites were read directly for a really fast access.

• Webserver storage well it should be obvious: if you need to store data to a server it is because the device shouldn't be the only owner of that data. But if you just need to synchronize the same App across different iOS devices (or even with a Mac-ported version of the App) you could also look at iCloud storage, obviously.

iOS data storing mechanisms

Yes. You are right with your understanding of data storing mechanisms.
But, apart from these 6 methods, another 2 methods which help to store data locally are:

i) Codable (protocol): used to save custom objects into a .plist file. It overcomes the drawback of the UserDefaults method that stores only built-in types data such as Int, String, Array, etc.

ii) Realm: It is a foster and easier database solution. You should also check its official documentation for more details.

All methods stores data into the Documents Directory. You can even print the path of document directory and open it in file manager to view data.

iPhone - different ways to store data, advantages and disadvantages

Plist files are another option if you want to manage your own storage on the file system. NSArray and NSDictionary provide methods for writing and reading those collections to and from plist files as long as you can store all of your data in one of the supported plist data types. See the Property List Programming Guide for details. It might be a good option if you can easily break up your data into distinct files and always want to load an entire file at once.

CoreData is a powerful tool, especially if you want to store a graph of objects. It might be an appropriate choice when you want to be able to store and load model objects easily.

SQLite is great if you want to store relational data and run queries against it. It might be a good choice if you want fast and efficient queries but don't need to convert the results into model objects (or have some reason for writing your own ORM layer).

As you mentioned NSUserDefaults is a convenient tool for storing user credentials but is not intended for larger volumes of data. It also allows you to expose settings in the settings app so that a user can set application behavior in one common location without launching your app.

Any form of file based storage may have additional value if you want to expose those files to the user through the File Sharing settings, allowing application data to appear in the iTunes Documents directory when synching to a PC.

---

Regardless of the storage mechanism you use every one of these options requires that you manage some sort of schema for your data.

You need track of the format your data is stored in in every version of your application. Any time you change your expectation of the format of saved data you need to support old versions. I see too many apps crash after an update because they do not handle data saved by old versions of the app or assume that users will have installed and run every version of the app instead of skipping some updates.

CoreData has some support for migrating data from one schema to another but it is something that requires developer work, awareness, and testing in all cases.

UserDefaults or Core Data?

NSUserDefaults as the name suggests (vaguely) should be used for storing preferences and app settings only. You should not be storing critical data and or user data into them.

CoreData is a full fledged persistent framework which supports large data transactions. CoreData allows you to build relational entity–attribute model for storing user data.

Please note that CoreData is a framework and can use SQLite, binary formats to store data (the default templates always use SQLite).

Example:

App preferences like show notifications, toggle switch settings, UISegmentedControl settings all go into NSUserDefaults. Whereas any data you might fetch using a web service like a list of all cities in a country, list of todos for a user go into CoreData.

PS: I don't recommend wiki for technical write-ups but to get quick understanding on CoreData, please refer here!

Pros of NSUserDefaults:

• Easy to store and retrieve data.
• Useful for storing default values with minimum fuzz.

Cons of NSUserDefaults:

• Not suitable for large data sets

• Performance hit when you try to store and load large amount of data
  All or nothing approach

Pros of CoreData:

• Reliable framework to interact and query against data

• Can be extremely fast when setup correctly (with relationships)

• Powerful capabilities

Cons of CoreData

• Takes time to master and learn the core concept

• Needs proper app architecture design to be efficient

• You cannot have a learn and implement in a day approach with CoreData

• As you improve your app, you need to improve your data architecture
  as well

• Migrating to new versions can be a pain if you are not careful.

Reference From HERE.

---

Related Topics