The "Mingled Content" Model of App Deployment

I wrote in "App Management and Sync" about our current approach to deploying iPad apps to students. I call this the "School Provides" model - we buy the apps in our account and deploy only those apps to our iPads.

Partly for curiosity and partly with a view to increasing flexibility and personalisation, I've been researching other possible models. The model I want to write about today, I call the "Mingled Content" model.

In a "mingled content" deployment, you have content (apps, mainly) on the iPad that have been purchased under two different iTunes accounts. For the purposes of this article we'll call them S for the "school" account and P for the pupil account.

Background

Schools want to deploy specific apps for school use. It's essential that teachers have a predictable baseline capability that they can assume when planning lessons (further reading: Run What Ya Brung).

We have found that flexibility is also important. It's highly desirable for the teacher to be able to stand in front of a class and say "hit the App Store and get this new app I found". At the same time, pupils want to personalise and really own the device - particularly in terms of their own music/video content.

In any 1:1 deployment, it is essential that there is a plan for "rapid return to service" when a device dies. When the entire educational experience is designed around the assumption that there will be 1:1 technology, it's simply unacceptable for a pupil to be without a device for an entire day or more.

My aim is to provide a complete on-campus backup and restore capability that will allow me to back up and restore a user's data to a new device in as short a time as possible. The question is whether I can do this for a mingled content iPad, so I did some research and here are the results.

Mingled Content

It's quite easy to end up with a Mingled Content iPad. You simply sign out of the App Store app from one account, sign in using another account and buy something. The iPad is mostly happy operating in this manner except that, to get updates, you have to sign in with each account and check for updates separately in the App Store.

The problem comes when you want to sync the iPad to a computer for backup.

Setup

Lets assume that the school provides a computer to sync to. The computer is authorised for Account S, the school account. Let's assume for now that we do not want to allow school computers to be authorised for pupils' own iTunes accounts.

Backup

When the iPad is backed up, iTunes will copy all the user data associated with every app on the device into the iPad backup file on the computer. This includes data and files created in apps purchased with Account P. iTunes will not back up the actual application binaries for any app that the computer is not authorised for.

After backing up we have, on the computer:

  • An iPad backup file containing the user data for every app that was on the device at the time of backup.
  • In the iTunes library, the binaries for the apps purchased in Account S only.

To test this, I took one of our spare iPads and synced it to a computer, installing some apps from Account S, then I installed some additional applications from Account P. I created some files in each app, then I backed the device up again. At that point, I got the familiar warning that the apps purchased from Account P could not be transferred to the Mac because the Mac was not authorised for Account P. Fine.

Restore

As we know, a backup is not a backup without a verified restore process. I took my Mingled Content iPad and erased it in iTunes with the Restore button. When it had finished, I opted to restore the iPad from its last backup.

Recall that this backup contains all the user data for every app that was on the device. When I restored the iPad, the apps I purchased through Account P were not present on the device. The apps from Account S had been reinstalled and their data was intact.

I then reinstalled the same applications as before from Account P. On launching the apps, I found that their data had already been restored to the device, even though the application was not present on the device nor in the iTunes library at the point of restoring it.

This is a useful result. It means that, in principle, the school can provide a full data backup service while letting pupils install their own apps from their own account.

The drawback is that restoring a device is not a one-click affair. School apps can be restored immediately but pupil-installed apps will have to be individually re-downloaded from the App Store on the device. Additionally, the problem of doing on-device updates for content from two accounts remains.

An Improvement

One way to improve the backup/restore situation would be to allow pupils to authorise school computers for their iTunes accounts. If this was done, it would be possible to transfer the application binaries from the Account P applications to the school computer. Then, there would be a complete backup of both user data and application binaries on the school computer that could be used to perform a one-click restore of all content to a new device.

The problem of updating mingled content would be essentially unchanged, however.

Conclusion

Whilst this behaviour is interesting and useful, I feel convinced that this is the most complicated and therefore the most error prone approach to app deployment. To be successful with this model requires a fairly deep conceptual understanding of how the App Store DRM is keyed to individual accounts, how the iTunes backup model works and how to manipulate the App Store application on the device.

Next week, I plan to write about the third possible model of app deployment: every pupil has their own iTunes account.