Question

In IOS store data. Each method has its strengths and weaknesses. Compare and contrast methods, and give an example of an app (it doesn’t have to be a particular app, just an “app type”) that is appropriate for each type

Answer 1

Data persistence is an important function of app based on any technology, be it android or iPhone. There are times when we have to work without an internet connection, which is where offline capabilities of a mobile app come into practice. In our previous post “local android data storage” we discussed the technologies in Android that support offline storage capabilities in Android based mobile apps. Here we will explore local iOS data storage guidelines for iOS apps intended to keep certain information locally. Local storage is meant for retaining web app data locally using certain frameworks, tools and methods distinctive to different platforms. For iOS storage there are different methods to choose from. The choice, however, depends upon what and how much data you want to store. Most of the times more than one method is required to implement local storage in iOS apps, as there are different persistence needs of the application viz. data gathered from web browsing, user preferences, and application settings. The most widely used methods for local storage implementation in iOS are:

• SQLite
• Property List
• Core Data
• NSUser Defaults
• Key Chain

Different methods serve different data persistence purposes, for example, SQLite is used for low-level relational database work while Core Data is a modeling framework for object oriented Cocoa Touch Applications.

Essential Guidelines for Local iOS Applications Data Storage

SQLite For iOS Local Data Storage

SQLite is a powerful lightweight C library that is embedded in an iOS application. This is used in various applications across various platforms including Android and iOS. It uses SQL-centric API to operate the data tables directly. Using SQLite C library for local data storage implementation in iOS applications, one needs to be very meticulous when passing in strings and arguments required for the functions. SQLite is very particular about the argument type given to functions.

SQLite Limitations

• SQLite is used to handle low to medium traffic HTTP requests.
• Database size is restricted to 2GB in most cases

Property List

Another most common method of storing data in iOS application is in Property List files. Documents in property list contain either an NSDictionary or an NSArray, inside which there is archived data. There are number of classes that can be archived into the PList, viz. NSArray, NSDate, NSString, NSDictionary and NSdictionary. Objects other than these cannot be archived as a property list and will not be able to write the file. One has to be very particular about listing items into the classes, for instance to store a Boolean or Integer object only NSNumber class is used. Boolean or Integer object must not be given to any objects in NSDictionary or NSArray.

Plist Advantages

• Plist files are very easy to read both for humans and computers
• Plist files can be used to specify some app environment values, like base backend URL, application keys, shared regex strings. They are a better fit for this, than let’s say, Swift classes.

Limitations

• Working with String keys can be error-prone
• It’s easy to break plist files with some unclosed </> key or value input
• You can only store small objects of primitive types

Core Data

Core Data is the method recommended by Apple for local storage of app’s data. By default, core data uses SQLite as its main database in the iOS app. Internally Core Data make use of SQLite queries to save and store its data locally, which is why all the files are stored as .db files. This also eliminates the need to install a separate database. In iOS this framework allows for two different database storage types but by default it is SQLite. Core Data allows you deal with common functionalities of an app like, restore, store, undo and redo.

CoreData is persistence and/or in-memory cache framework that consists of a very powerful set of other tools that can be used within the app. In most common examples CoreData is used as a wrapper for the SQLite database and it’s used to save and present any type of user data.

Functionalities

• Query-free SQL database wrapper
• Easy to read data on the main thread
• Easy to use background thread data saving
• Easy to setup in-memory database (e.g. for caching, or unit testing)
• Out of the box support for automatic migrations of the database between app releases
• Easy to setup database modeling tool (with Interface Builder)
• Core Data Advantages
• CoreData is simple to set up and use
• Lots of additional tools provided by Apple for fetching data (https://developer.apple.com/documentation/coredata/nsfetchedresultscontroller)
• Speed & Performance: Possibility to be a cache when setup `in memory `
• Out-of-the-box database migrations (simple one)

• Core Data Limitations

• Quite advanced threading policy
• Being forced to use NSManagedObject subclasses for every new object in the database
• Sometimes NSManagedObjectContext have problems with synchronizing database changes

NSUserDefaults

To save properties in any application and user preferences, NSUserDefaults is one of the most common methods for local data storage. This is used to save logged in state of the user within an application, so that the app can fetch this data even when user access the application at some other time. In some of the iOS apps this method is used to save user’s confidential information like access token.

UserDefaults as name specific can be used to store default information about the application or its users. For example, the user should be able to specify the default playback speed or currency that you should display when presenting some stock data. These preferences should be application specific and should be persistent between app launches.

UserDefaults is an NSObject subclass that gives us synchronous reads and writes (on cache level) and asynchronous persistence level.

Advantages

• UserDefaults is easy to use, with a simple API
• Thread safe (you can read and write values from any thread), without worrying about synchronization
• UserDefaults is shared between the app and the app extensions

Limitations

• It is possible to easily override the value for this same key (key collisions)
• UserDefaults is not encrypted
• Unit testing user defaults can occur with some false positives.
• UserDefaults can be altered globally, from anywhere in the app, so you can run in inconsistent states easily

Key Chain

Most of the time developers avoid implementing key chain method to save data as the method follows a complicated procedure. If the device is jail broken, none of your data is secure. This is the most secure and reliable method to store data on a non-jailbroken device. Simple wrapper classes are used to store data using key chain method. The code for saving data here is similar to the code for saving data in NUserDefaults. The syntax used is very similar to that of NUserDefaults. Using these methods developers can also reduce the vulnerabilities of iOS applications, by storing local data in a secure manner. However, this is not possible for a jailbroken device, where the attacker can access everything from PList files, key chain and other method implementations. Using the methods listed above developers can make it tricky for attackers to reach the locally stored information. Also, iOS local storage increases the offline capabilities of a mobile application, thus making it less internet dependent.

Apple Keychain is a very popular and functional Swift tool that every iOS and MacOS user is using. It can be used to save passwords, secure notes, certificates, etc. In general, Keychain is an encrypted database with quite a complicated and robust API.

Use Keychain when you need to save sensitive user data, such as passwords or login credentials.

Advantages

• All items saved in keychain are encrypted (Keychain is the most secure data persistence layer in iOS)
• There is a lot of open source wrappers with user-friendly Swift APIs
• Once again security
• Thread safety

Limitations

• There is no handy and old-fashioned Keychain API, so you usually end up depending on an open-source project
• Hard to unit test, unless you create your own wrapper around it
• Speed: Reading or saving a lot of information into Keychain can be slow
• Not recommended for storing large objects