Options for persisting data on an iOS device

Now you’re ready to save and persist data for your iOS app. What choices do you have? They’re covered in this post.

This document was most recently updated in September 2013.


An iOS device is a computer that runs iOS, a UNIX-based operating system.

Our iOS apps can work with the device’s file system to persist data. Obviously, the file system is UNIX-based.

Each iOS app runs in an isolated runtime environment. Additionally, the part of the file system that the app has access to is isolated. An app can work only with data in its own app bundle (read only), and its isolated file system portion (read and write). One app cannot get access to another app’s file system area, or to the device’s system area.

When an iOS app is installed on the device (or on the iPhone Simulator), the app’s file system storage area is empty. Therefore, if you need to provide getting-started data for your app, then you need to do one or more of the following:

  • Generate the data programmatically, on first launch/run
  • Deliver the data in your app bundle, and programmatically copy it to the file system area on first launch/run
  • Obtain the data from a server, using the device’s network connection


Each app’s file system area is organized as follows:

  • It’s “root” contains the app bundle, and three folders…
  • The Documents folder is to be used for storage of the app’s data; it gets backed up (via iTunes or iCloud)
  • The Library folder is to be used for preferences storage and a few other purposes; it gets backed up
  • The tmp folder is to be used for “temporary” file system operations


FYI – Locating your app’s file system area when using iOS Simulator

If you are using the iOS Simulator with Xcode, you can use Finder to locate your app’s file system area. Here’s how:

(your home) > Library > Application Support > iPhone Simulator > [ version ] > Applications > (unique app ID)

Each application is located in a folder with a “unique app ID” name. Xcode works with the iPhone Simulator, and the result is a name like this: 1B999F52-8B09-416A-A94B-5B4CE9C98697


Access the file system area programmatically

There are two example apps with fully-working code to access the file system area. In this section, the highlights are presented.


Access the app bundle

You can access the “app bundle” with the Foundation kit NSBundle class. When called with the correct method, it returns a file URI to the app bundle, and the data file in it that you want.

For example, in the “Notes plist” example app, there is a wk3app5.png file, in the app bundle. Use the – URLForResource:withExtension: method: .

NSURL *urlToFile = [[NSBundle mainBundle] URLForResource:@"wk3app5" withExtension:@"png"];

Then, when you NSLog [urlToFile description], you’ll see:


If you’re new to the iOS or the Mac OS, an app bundle appears in Finder with a generic icon (or a custom icon if the programmer has provided one), and a name that matches the app’s name. So, to us, it appears as a single icon object. In reality. an app bundle is a directory, with a number of files and folders within it. In Finder, you can right-click the app bundle icon, and “Show Package Contents” to see the files and folders.


Access the app’s Documents folder

The NSFileManager class enables you to get a file URL to the app’s document folder. Here’s the calling convention:

NSURL *urlToDocumentsDirectory = [[[NSFileManager defaultManager] URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask] lastObject];

Then, when you NSLog [urlToFile description], you’ll see:


You can append a resource name (i.e. a file name) to the end of this NSURL instance, by sending it the – URLByAppendingPathComponent: message.

Note: Starting with Mac OS X 10.6, Apple recommends that we use URL-based objects for file system paths. You may see older examples “out there” that use string-based objects, but please don’t consider them to be authoritative.


Options for persisting data

iOS offers a number of options for persisting data:

  1. Property list (plist)
  2. Archiving
  3. Core Data
  4. Storage located on a server, accessed over a network, using an web services API

In this course, we will not use Archiving much, if at all.

Soon, we will work with Core Data, and use it as our main data management and persistence scheme. Later, we will work with server-via-network web services based storage.


Typical use cases / scenarios

In the near future, we will cover these typical use cases for data on an iOS device:

1. Open and read data that’s located in the application bundle

2. As a follow on to use case 1 (above), process and write the data to the app’s local file system

3. Use a plist as a read/write storage format, and store the plist file in the app’s Documents directory











  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: