Setting up an Automated Build in an iOS environment – part 5
by George on Jun.19, 2011, under Coding, Project Management
I’ve recently been trying out Testflight as a method for getting beta builds out to testers. Testflight handles a number of things for you – over the air distribution of builds, notification e-mails, download stats and more. It’s a great system, but my first thought when I started experimenting with it was: “Can I incorporate it into my build system?” Fortunately the answer is yes, in fact it’s dead easy. Let’s see how it’s done…
Setting up…
I won’t go into all the details of setting up a Testflight account, it’s fairly well covered on the site. What you will need to do is set up one or more ‘teams’ for beta testing. Once you’ve done this, it’s time to investigate Testflight’s upload API.
Automated uploading
Most pages on the Testflight site have a set of links at the bottom, one of which is ‘Upload API’. This page gives details of how you can upload a build programmatically. You’ll need to find a few details – an api token and a team token. Both of these can be found by following links off the Upload API page. Once you’ve got these, we can use curl to handle the communication with Testflight .com:
curl http://testflightapp.com/api/builds.json -F file=@yourapp.ipa -F api_token='your_api_token' -F team_token='your_team_token' -F notes='This build was uploaded via the upload API' -F notify=True -F distribution_lists='Your Team Name'
And that’s all there is to it! I’d recommend trying this from the command line until you’re happy that builds are uploading correctly, then simply drop this command line into your build system as a final build step.
I’ve been using this for a while and it works well. The first time you create a build, your testers receive an email – if they read the email on their device, they’ll get instructions for setting up Testflight on their iDevice. Having done this once it becomes a one click process for testers to get new builds. Not only that, but you as the team leader will know who has downloaded the build, and on what device!
Just a few of issues…
Overall I’m really happy with Testflight as a system. There are some things to be aware of though:
- Testflight only works on newer devices / OS versions (4.0 and later, I believe).
- I’m not clever enough to interpret the results of curl to determine if an upload fails, so currently I get a ‘build succeeded’ even if the upload fails. If anyone can offer some advice on how to do this, I’d appreciate it.
I hope you find this useful – I know I do – one click to go from Source Control to having a new build in tester’s hands? Magic.
Related posts:

October 11th, 2011 on 8:08 pm
This is awesome! Thank you so much!
Tina
January 18th, 2012 on 10:28 pm
Excllent tutorial.. One last step is missing to make it really awesome
After testflight uploads the builds is there a way to automatically install the build on an actual device ?
Currently our testers need to manually open the build link in email and click on install prompt to get the build to actual ipad/iphone
January 18th, 2012 on 10:30 pm
Hi Rajesh,
Glad the article was useful. As far as I know there’s no automatic way to install the app, and I doubt it would be possible. I don’t think Apple wants anyone installing anything remotely like that – there’s too much room to abuse it.
If I’m wrong and you find a way though, please let me know!
January 19th, 2012 on 1:23 am
Thanks George,
I was wondering if one could write a small objective C app(which would reside on the device) to click on the testflight build link URL so that the build installs on device.
This app can be controlled from the host mac machine to which the device is plugged in… (so that it knows when to click the link)
Would that be a kind of working option? (I am not good in implementation , so just a thought
)
February 15th, 2012 on 9:19 am
George,
I’m working on our ABS and your articles have been EXTREMELY helpful. I work for a larger company so we have at least 3 different provisioning profiles that our ad-hoc builds have to be signed with. We also build our app from a workspace as we have it linking to an engine that is constantly in flux. My understanding of the xcodebuild command leads me to believe that the only way that we can create these builds automatically is to create 3 configurations, each of which has the right provisioning profile selected, then create 3 workspace schemes that utilize these configurations and then call xcodebuild -workspace myworkspace.xcworkspace -scheme ProvScheme1, etc, etc.
What I don’t like about this is that we already have quite a few configurations for different types of builds and when we build from xcode, we manually switch the provisioning profile for the build we need. The above solution would add even more configurations and bloat our configuration list. I also tried creating xcconfig files for each configuration and passing that into xcodebuild command but I believe that when you do that with workspaces, it applies that configuration to every project in the workspace, which isn’t ideal.
So I was wondering what you thought about this or if you have run into this issue at all in your build system?
Thanks again!!
February 15th, 2012 on 10:03 am
It appears it is as simple as specifying CODE_SIGN_IDENTITY=”iPhone Distribution:XXXXXX” as an argument to xcodebuild!