Optimizing Apps for Shared iPad

Shared iPad allows you to deliver personalized experiences on an iPad shared by multiple users. Follow these best practices to ensure that user-specific data is cloud-based and efficiently managed.

Since local data may be purged when switching users or when the device is reconfigured, it’s important to ensure persistent storage, depending on your application architecture and the type and volume of user-specific data.

Testing Shared iPad support

If your app is cloud-based or doesn’t store data locally, your app may already support Shared iPad.* You can test if your app works well with Shared iPad by doing the following with two single-user iPad devices signed in with the same Apple ID:

  1. Run your app on an iPad that’s signed into your Apple ID.
  2. Interact as a user by creating, changing, or adding content.
  3. Sign out of your Apple ID on this iPad.
  4. Sign in to a second iPad using the same Apple ID.
  5. Download and run your app.

If your app picks up where you left off, your app supports Shared iPad. This case also covers the unlikely event that Shared iPad has to purge the data for a given user or app.

Indicating purgeable local storage

Supporting purgeable local storage means that you either have no persistent content of consequence (for example, a calculator app), or your app ensures that any content that requires persistence is stored in the cloud. Once you’ve implemented the Data Management and Sync best practices, you’ll want to indicate your support for Shared iPad by setting the NSSupportsPurgeableLocalStorage key to “yes” in your project’s info.plist. Doing so indicates that your app supports having its local data purged when the user signs out. This will show customers using Apple School Manager that your app works well with Shared iPad.

Data management best practices

Store all user data in the cloud. Shared iPad requires a cloud-based synchronization model for any data required to persist between uses of the app. Send data to your own backend using NSURLSession, or use iCloud, NSUbiquitousKeyValueStore and store credentials in Keychain.

Fetch remote data on demand. Since all data associated with a given app may not be required at any given time, develop a download strategy that ensures you only download what’s needed when it’s needed or just before. Rather than bringing back all known user content you may need in the app, consider only pulling what’s required in the current context.

Sync data as it changes. Sync user entered or created data as you get it. Be sure to synchronize during applicationWillResignActive at the minimum, but keep in mind that waiting too long or holding an overly large batch for synchronization will provide an inferior user experience and may lead to data loss in rare cases.

Store first launch or progress flags in the cloud. If your app determines the need for a first launch experience based on a flag currently stored in the local file system or NSUserDefaults, you should move these per user flags to NSUbiquitousKeyValueStore and check there before presenting your first launch experience.

For more information on the NSUbiquitousKeyValueStore, check out the NSUbiquitousKeyValueStore Class Reference and PrefsInCloud sample project.

Limit background task assertion requirements. Limit the amount of work you do in background task assertions to the minimum needed to ensure data consistency and synchronization — generally calls to NSURLSession or iCloud APIs to upload the user’s data. These APIs provide support to continue the network operation without blocking the transition between users.

Indicate purgeable local storage support in your project PList. Indicate support for Shared iPad by setting the NSSupportsPurgeableLocalStorage key to “yes” in your project’s Info.plist. Doing so indicates that your app supports having its local data purged when the user logs out.

Sync technologies

Sync using NSURLSession. Apps using NSURLSession with the appropriate background configuration to push user-specific settings or data will be assured that their uploads will continue after the user has switched apps and more importantly after the current user has signed out on a Shared iPad.

For more information on NSURLSession, watch the WWDC video Networking with NSURLSession and review NSURLSession Class Reference.

Synchronize credentials via Keychain. Keychain on Shared iPad provides automatic synchronization across devices using the same Apple ID. Storing credentials and other lightweight information in Keychain via Keychain Services API ensures they will be secure and available wherever the user signs in.

For more information on Keychain implementation, check out the Keychain Services Programming Guide.

Synchronize data via iCloud. Implementing support for iCloud Documents and Key-Value Storage APIs means your user content will be in-sync without having to explicitly manage that synchronization process. While CloudKit is more transactional and under your explicit control, CloudKit operations are designed to ensure data committed arrives in iCloud storage even if the app is exited or the user signs out.

Check out the iCloud Design Guide for which storage API is best for your app.