When devices are made to work a shared-usage model, for example, many nurses using the same iPad during shifts at a hospital, one method to restrict access and standardize the experience would be to lock the device to a single app. This is referred to by different names based on how it is initiated, and it can be achieved with the tools that we will discuss in future chapters. The device shows only the designated app and never goes to the home screen (also referred to internally as the Springboard). The Home button is essentially disabled and Control Center (which is accessed by swiping up from the bottom edge of an iOS device) is also not accessible. This can also enable a kiosk-type experience, where the device is protected from misuse by dictating that only a single app can run.

In recent releases of iOS, developers have been granted APIs to enable app lock when they enter a certain state within the app or until a specific requirement is met...

Historically, very few affordances were made when one developer wanted to communicate with the application data of another developer. URL schemes were manipulated for this purpose and they allowed a developer's app to be summoned by an identifier that was usually based on the bundle ID. In the last few major releases of iOS, there was at least the affordance for shared credentials to be accessed between apps by the same developer. This sharing of a keychain by an app group now also includes the sharing of file storage and preference data, which was previously accomplished by separate accounts with third-party sync services like Dropbox. iCloud Drive has been introduced to perform similar ad hoc file storage and sharing tasks. If this sounds somewhat limiting, it's because historically it has been, but we will touch upon the new ways in which app functionality and data can leak out from the one-app-at-a-time silo after we discuss how app data can now pass more...

As discussed in the previous chapter, the keychain is known as a way to centrally store and manage credentials and other secret data that are in use by applications on the behalf of the user, carried over from OS X. There is also the concept of a keybag, which in practice is a grouping of secrets (or more practically, keys) that allow the system to manage the moving parts around specific interactions. Besides, when used by the system itself to manage the encryption of the data, these deal with primarily when a backup will run either over Wi-Fi to iTunes, when tethered by USB to iTunes, or while the device is plugged into a power source and locked as a requirement to send to iCloud Backup.

Explaining keybags as a concept is a minor point, but there has been terminology confusion regarding things such as the securing of apps with digital rights management and the use of the keychain, neither of which are directly related. To summarize, keybags are an abstraction for secrets...

One of the greatly anticipated features of iOS 8 was the concept of Extensions. While shuttling around the state of an application is all well and good, extensions allow apps to have their functionality appear in new places.

This is implemented through the addition of specific abilities presented to developers that are referred to as extension points, with the most anticipated being third-party keyboards. A more popular keyboard that is available for other platforms is Swype (though I am personally waiting for the return of Palm's Graffiti), which allows more fluid, one-handed text entry.

Apple grouped other possible extension categories under Today widgets (Today being a newly expanded view in Notification Center on iOS and Mac), photo editing enhancements (for example, filters from popular apps like VSCO Cam), document providers for importing files from popular sync services like Dropbox, and share providers like the pre-existing but system provided Facebook...

As we mentioned in the beginning of the chapter, a code signature is placed on the app bundle itself with additional protection, so that the signature is verified not only when the app is installed, but also at runtime when the app is launched, to make sure that it has not been modified in the meantime. This is for stability as much as it is for security, since code that has been modified or allowed to run roughshod on the system can cause the device, which we might just want to be able to use to call 911 in an emergency, to crash.

We spoke about a mobile user which would have a home folder. Unlike the common consumer computer OS, the data storage location of an app is randomly generated and kept separate from the user (besides the containerization of specific preferences that help sharing among a developer's apps, so those settings persist even if an app is deleted). There are frameworks, which are shipped by Apple in its SDK, that encourage storing...