Data Management
Like many (perhaps most) apps, Pragmatic Podcasts is heavily dependent on the network for its functionality. It fetches lists of podcasts, presents them in a UI, and lets us choose one to play. At the moment, we’re really not managing any of the user’s own data. But we certainly could. Let’s say we wanted to remember all the podcast feeds our user adds with the plus button. We’d need to save those feed URLs somewhere. And with just that feature, we’d be in the data management business.
Persistence APIs
This gets us into the realm of data persistence: how to save the user’s data from one session of the app to the next. This might not be as obvious a concern as it is on a computer, since iOS doesn’t put the filesystem front and center. But make no mistake: there is a filesystem, and apps can use it.
In iOS, apps cannot access the filesystem outside of their own reserved space on the system. The app has a directory that contains folders for documents, caches, temporary data, and other specific purposes. The directories meant for long-term use, like documents, are backed up when the iOS device syncs with iTunes.
To access the filesystem directly, we can ask the FileManager class for the URL of the app’s directory, then create paths to access folders and files with FileManager.
It’s possible to read from and write to files with a low-level Stream API, or by using the read/write methods of the older NSData class that Swift’s Data replaced, but usually neither of these is the right approach. If we want to work with documents, the best way to do it is with the UIDocument class. This is a higher-level abstraction, with which we just write a pair of methods to save our document object to a Data or instantiate an object from a Data. The framework takes care of the actual I/O, so we never have to write to streams byte-by-byte like with a lower-level approach. As a bonus, UIDocument also allows us to store our documents in iCloud, where they can be synced with the user’s other devices.
Alternatives to Files
As a simpler solution for very small amounts of persistable data, we can ignore the filesystem altogether and use UserDefaults. This class is just a key-value store, meant for things like app preferences. The defaults are stored for us by the filesystem and are available on future runs of the app. They can also be exposed by the main iOS Settings app.
For secure data, like a user’s passwords or other personally identifying information, iOS offers Keychain Services. The keychain is a cryptographically secured data store that our apps can use for storing user data long-term (if backed up to iTunes, it will even survive the device being wiped), without us having to implement the crypto features ourselves. Unfortunately, the API was written in C and is hard to use from Swift, but there are a number of open-source Swift “wrappers” to make using it easier.
Databases
Sometimes we want more than flat files or key-value stores: lots of apps need full-on databases, so they can store a lot of data in a structured form and access it quickly. iOS ships with SQLite, a simple relational database that supports most SQL (Structured Query Language) expressions. SQLite has a C-based API that can be called from Swift, albeit with some difficulty.
Core Data offers a higher-level approach to data persistence, giving you the power of SQLite without having to write and execute the SQL statements yourself. Instead, with Core Data you create entities and their relationships with a graphical editor in Xcode, then let Core Data take care of the rest. Pragmatic Programmers has a whole book on this topic: Core Data in Swift: Data Storage and Management for iOS and OS X [Zar16].
User Data Services
Finally, there are a number of special-purpose frameworks that allow third-party apps like ours to interact with the user’s content and data stored on the device and typically managed by Apple’s built-in applications.
For example, the Music Player framework allows any app to access the Music app’s library of songs, audiobooks, and podcasts. Apps can play these items independently, or set the items that the Music app itself is playing.
The user’s photos are available by way of the Photos framework. This API lets apps query the photo database, get low-res thumbnail images immediately, and pass in closures to receive large full-resolution photos, a sometimes time-intensive task when dealing with 12 megapixel photos taken by the iPhone 7.
If the user has built up a database of names, addresses, and phone numbers, these are available through the Contacts framework, which has a rich data model for handling things like contacts with multiple phone numbers and email accounts for different purposes. For working with entries like boarding passes and concert tickets in the Wallet application, apps can use the PassKit framework.
Another thing many users store in the Settings app is their account information for social networks like Facebook and Twitter. Using the Social framework, third-party apps can ask to use these credentials, post to those networks with a built-in view controller, and make authenticated API calls to download posts or perform other service-specific actions.