An AdHoc build is how you get iOS apps onto an Apple device without going through the App Store. They are typically used for testing. I was asked this question recently, and spent 15 minutes writing up this reply, so I thought I’d post it here. The obvious caveat is that it can of course vary from project to project. A bigger more complex project has more “moving parts” that can need fiddling with when creating a build.
So… How long does it take to make an iOS AdHoc build?
I use TestFlight to distribute my AdHoc builds, and typically, I tell clients an AdHoc build takes between 15 and 30 minutes to complete. Thankfully this work “stacks” quite a bit, so doing a few of them at once might only take 20 or 30 minutes. This process basically just involves opening the project, verifying a few settings related to provisioning profiles and “targets”, building an “Archive” of the project, uploading the new build to TestFlight, and writing some release notes as well as picking the users to receive the build. (Thanks to the awesome TestFlight OSX app, those last two steps can be done while the upload is in progress.)
This assumes, however, that all the devices are already registered with TestFlight. Everything takes longer when I need to add additional devices. This stacks too, so adding 1 to 10 or 15 new devices only takes another 15 or 20 minutes. The main additional thing that I need to do in this case is upload the device identifiers for the new devices to Apple’s provisioning portal, and download a new (or updated) provisioning profile that includes those new devices. This additional work has to happen BEFORE I can make the AdHoc build for those devices.
What I find frustrating is when all these tasks are split up over the course of hours or days. For instance, when I’m asked to send a build to some new individual, but they’ve never used TestFlight, and aren’t yet registered there. Then I have to send them an invite, wait for them to accept the invite, wait again for them to register their device, then finally I can get their identifier and begin the process. This means either waiting for the new person before creating the build (sometimes this can take days, of course!), or just creating two builds, one with the devices I already have, and another when I get all the important information from the new person. Considering the adage that a “a 15 second interruption results in 15 minutes of programmer downtime” (which is more or less verifiable), these build requests can really add up to lost productivity for me.
One final note about what AdHoc builds are not.
After an app is in the app store, unless you are testing a new version, you should really be using that version, and not an AdHoc build. There are many reasons for this, but notably: 1) AdHoc builds will expire when the provisioning profile expires. 2) You get the peace of mind that what you are seeing is what your users are seeing. 3) You will get the updates via the app store, as your users do. 4) You can instal the app on multiple devices without needing to provision all of them. Don’t forget about using promo codes to get “free” versions of apps to your testers or employees after an app goes live! (In my experience, you rarely use all of them for press as you should, and you get a “fresh” batch after each update anyway.)
AdHoc builds are an integral part of iOS app development, but creating them is annoying to me because it’s not programming. Of course, neither is wring this blog post.