Ad Hoc Redux

So as pointed out in comments on yesterday’s automated build post collection, if you’re thinking about that kind of thing you should be considering what kind of method you’re going to use for ad hoc build distribution; and that’s a good excuse to round up the latest developments on that front since we first noticed wireless options for investigation as well.

Personally, we’ve found no compelling reason to switch from iOS Beta Builder to meet our ad hoc distribution needs so far, and we note that it’s now up to version 1.5 and headed for the App Store; and apparently there’s also some interesting forks,

… There’s a fork with better support for using Dropbox as the storage medium – interesting. There’s also full command line support, helpful for people that want to script the entire build process…

that command line support being particularly interesting, and documented here:

iOS Ad-Hoc Beta publishing directly from Xcode

If you don’t want to use that for some reason, here’s a couple posts on scripting xcrun directly for use with Hudson or whatever:

Automating Over The Air Deployment for iPhone

So there’s your dead simple solutions.

You want to step up the code involvement a bit, the Hockey framework has moved along nicely since we first noted it, hitting version 1.0 a few days ago and apparently having some serious upgrades planned for version 2.0. It requires setting up a server, and optionally integrating a client library into your code, but in return you get a variety of statistics on your installs and the client library provides convenient in-app upgrading instead of requiring the user to go back to the web to download each release. Which are no doubt valuable features if you have a large beta tester pool, but we haven’t seen that need yet, it’s rare there’s more than a couple people we’re ad-hoccing out to, so we haven’t felt the necessity to go to the effort of figuring out how to set that up so far.

What is completely new in recent months is the appearance of a fair collection of web services to accomplish these tasks. In alphabetical order:

AppMakr has a service called AppDrop, just for their customers it seems;

Diawi is a service that … well, actually, we don’t see where there’s any advantage at all over posting BetaBuilder’s output on your own site;

TestFlight seems to be getting the most buzz, and it certainly is a very pretty website indeed, and helps connect you with testers apparently. Which is a minor point in its favor … but we’re still not seeing that there’s any compelling reason to use it rather than post your own distributions via BetaBuilder or Hockey.

Also, in the particular case of beta build distributions, we’re rather opposed to introducing another possible point of failure by using a third-party service. Scripting our builds to deploy them to our own server suits us rather better. Especially since those services are all apparently free right now, but with no readily apparent means of monetization, counting on them sticking around long-term seems a little iffy. Basing your workflow on either of the open source solutions strikes us as rather safer.

But hey, it’s quite possible we’re overlooking something; if any of you Dear Readers have some compelling reason to build your ad hoc deployment system around any of these third party services, please inform us!


Note followup post about the renamed HockeyKit and promised hosted service!

Alex | February 4, 2011
  • Andreas Linde February 5, 2011 at 6:49 am
    Hi, just a small note: the client in Hockey is not required, it is optional. The server can run fine on its own to distribute the builds via the website. The client lib will enhance the upgrade process and experience for the testers dramatically. So this is highly recommended to use :)
  • Alex February 5, 2011 at 9:13 am
    Rephrased to make that clearer, thanks.

Leave a Reply