One of the pleasant surprises I learned last year at WWDC is that Apple uses Jenkins to automate their iOS app builds. Since we were already using Jenkins to do the same thing at the Day Job, it was a nice confirmation that we had taken the right approach.
However, until recently, getting Jenkins to fire off an Xcode build, bundle it into an IPA, and sign it correctly was a real pain. Thankfully, in 2012, a Jenkins plugin for Xcode integration was released. It can be installed directly from the Jenkins plugin management page, and once installed, gives you a new build step called Xcode that you can add to a build.
The nice thing about this plugin is that it handles just about every possible thing you could want to do in Xcode. You can build based on project or workspace, select specific schemes and targets, and even include your keychain password and have the resulting IPA file signed with the appropriate provisioning profile for an Ad Hoc or Enterprise distributed app.
It can also look for OCUnit results in the build stream and automatically generate trend graphs for you of your unit tests. I’ve taken this a step further, by invoking hfcca.py before running the build (using the -X option), that generates Cpp NCSS compatible output, and then using that plugin to create code complexity and NLOC trend graphs for our builds (as well as failing them if they exceed our cut-off for acceptable CCN limits.)
To complete the process, I’ve also written a Perl script that gets run by the build, and that drops the finished IPA into a known location on a web server, with a corresponding plist file, so that our testers can download and install any of the various Enterprise-signed builds without me having to lift a finger.
The last step you should take to put everything on automatic is to set your SCM to poll periodically, so that you get the benefits of continuous integration. With all these steps in place, you can sit back and get caught up on your TiVo backlog while your builds purr along unattended.