Apple’s Ad Hoc distribution process is a godsend for iPhone beta-testing, but a right pain to use in practice. I’ve tried several different approaches for creating and managing Ad Hoc testing; this article describes the one I now use for my National Rail Enquiries for iPhone application.
(A note before we get started: This article assumes some pre-knowledge of iPhone app distribution. I can’t hope to cover the whole mobile provisioning process here, but I would recommend Ralf Rottmann’s introduction as a good starting point for the uninitiated.)
The big problem with Ad Hoc distribution is this:
- you need to sign your application in order to install it onto a list of allowed devices
- you do this by creating a “mobile provision” file for a given list of devices, and sending the file to your users (who install the app and the provision file onto their phone)
- whenever the list of devices changes, you need a new mobile provision file for the new device
I started out with a single mobile provision file for all of my beta testers. As new beta testers signed up, I would add their devices to the same mobile provision file. I would use the latest file each time I released a new beta, and would send out the latest file with each beta release.
The problem with this approach is that the mobile provision file has the same file name each time, but a different Unique ID. It looks the same, but it’s actually a completely new provisioning file as far as Xcode and the iPhone are concerned. If I call my mobile provision file “NRE Ad Hoc.mobileprovision”, all future copies of the file will have the same name, but a different unique ID. This makes it very hard for users to know which version of the provision file they have installed on their iPhone, leading to problems installing the latest beta builds.
My next approach was to create a mobile provision file for each device, and build different copies of the app for each device. This removes the need to send each user a new mobile provision file when you release a new beta. This makes life easier for users (they only need to install a mobile provision file once), but is a right faff for the developer, as you have to manage and build an increasing number of copies of the app each time you release a new beta to more users. You also have to be extremely careful to send the right build to the right user. Finally, mobile provisioning files expire after a year and have to be reissued, which means that in 12 months you’re back with the same problem as above – multiple mobile provisioning files with the same name.
So my new approach – which has worked well so far – is to create a new Ad Hoc mobile provision file for each beta release. For example, when I release v1.1 beta 1 to my beta testers, I create a new Ad Hoc mobile provision file called “NRE_1_1_0_beta1.mobileprovision”, and assign every single beta testing device I know of (at that time) to that mobile provision file. I then build one Ad Hoc copy of the app, signed with this mobile provision file, and send the app and the file to all users. This requires each user has to install a new mobile provision file each time they receive a new beta, but this makes it much easier to see which provisioning files they have installed on their device. It also avoids the 12-month timeout problem, as by the time “NRE_1_1_0_beta1.mobileprovision” has timed out, I will definitely have released another beta release to the same users with a new provisioning file.
The ideal approach would be for Apple to include the mobile provision file in with the Ad Hoc application build. This way, all the user would have to do would be to drag the application onto iTunes, and the appropriate mobile provision file would be installed too. Sadly this is not currently the case.