After several months of hard work and some great help from the community, we declared the current state of the Hockey framework source as 1.0. It has been a great ride so far.
Back in August 2010 we found out about a new iOS mechanism to install Ad-Hoc builds over the air by reading this blog post. Only two weeks passed from the first idea for a framework for developers that can be used to distribute beta versions more easily to the first public release. And since then the framework got quite some attention in the iOS developer community. Other solutions also emerged, like the Mac app iOS Beta Builder, or the web services TestFlight, Diawi, AppSendr, and some others. They all share the same goal: Simplify beta testing!
The Hockey approach was and still is special, since it not only allows easy self-hosting. Hockey combines that with a nice web interface for app installation and, more importantly, with an optional client framework that developers can integrate into their apps to simplify updating for their testers even more. On top of it, it also is completely open source, available on GitHub.
Hockey consists of a few PHP5 files for the server component which handle most of the magic automatically, there is no database required. All the developer needs to do is to create one subdirectory per app, and place the .ipa distribution package and the .plist manifest file into that directory. And whenever there is an update ready for distribution, simply replace these files. The Hockey repository even contains a sample shell script that can be integrated into the Xcodes' build process to handle the upload automatically. This way publishing a new beta version is just a matter of seconds. There are several options available to further improve the look & feel, e.g. by adding an app icon, release notes and more.
The web interface
The server provides optimized web interfaces for all the different clients, from desktop browser over iPod touch and iPhone with iOS4 and iOS3 to iPad. And if the developer wants to distribute beta versions of multiple apps, this is also taken care of automatically. The website even contains detailed information on how to install an app via iTunes if necessary.
Better, but not great yet
So we solved one issue with the web interface: How to distribute an initial version to our testers. But that is far from everything we need. How about updates? We used to send out emails to a mailing list, informing our users about a new beta version. And it happened quite a few times that there were two or more versions a day, because development had such a fast pace at times. But this ended in lots of emails in the users mailboxes and quite a big burden to install the apps. Ok, now they can use the web interface to update them instead of going through the horrible iTunes installation experience. But anyway, there is something else wrong with this process besides all the mails. The testers are still bothered way more than necessary: Opening mail, reading the mail, tapping on a link to the website, choosing the application and tapping on installation and then on the install button again. So there are at least 6 steps for each update. And don't forget at least one more tap to archive or delete the mail. Well, the mail could already contain a direct link to install the app. That would save two taps but still, it just doesn't feel right.
The client framework
The idea was pretty simple: if beta testers do really test, why not presenting everything from within the application when they test. We call it In-App-Updates. Suddenly we got rid of all the redundant mails and all the unnecessary tapping. The experience is absolutely seemless and integrated. Beta testers don't have to care about anything else than testing! The client framework alerts the user of new updates, lets them view the new release notes and version information and starts the update process whenever they are up to it. Additionally the framework works for iOS 3 users identically, but since the OTA app installation is not available for this system there will be a hint to download the update from the web interface on their desktop computer. The client framework helps all testers, whatever iOS version they are running and is localized in English, German, Russian and Spanish.
Knowing the status
The testers should be happy now, and the developer too. From publishing to consuming a beta version everything is optimized and mostly automated. In our case, this led to provide new beta versions far more often than ever before, since we knew the testers won't get bothered more than necessary. But on the other hand, there was one more information missing: Is the latest version being tested at all?
Since the clients already do check for available updates, it was obvious that we can get pretty much all the information needed to answer this question at least roughly. The client sends additional information to the server like the devices' UDID, the device type, iOS version and app version. This information is collected and presented at the statistics page of the web interface including the timestamp of the last update check. This alone gives a pretty good overview of how well the app should be tested.
Try it yourself
If you want to host your own easy to use beta app distribution server, or also want to leverage additional benefits by integrating the client framework into your apps: simply head over to the Hockey GitHub repository and download the 1.0 release version via the downloads button. It's all free under the MIT license! What are you waiting for? ;)
One more thing
So far it has been a great and fun ride working with and improving the Hockey framework as well as the server components. But there is no reason to retire now. The next major version 2.0 is already being heavily worked on and some very talented people joined in bringing Hockey to the next level. To get a sneak peek at the improvements, check out this teaser images:
The new version isn't far away, and we'll reveal more information in the upcoming days and weeks. So stay tuned!