For the longest time it seemed that releasing an update to an iOS app was a random whack-a-mole process that I’d invariably get wrong in some way. It was maddening, especially since iTunes Connect has only recently become a decent web application. By switching to Jenkins for continuous integration of my iOS app builds I’ve greatly improved my process, but things didn’t really improve until I created a checklist for keeping track of my releases.
Since I’ve been asked many times about this very topic recently – both at work and on Twitter – I thought I’d write a post about how I bring some sanity to my release process so my app updates are timely and predictable.
Continue reading “My App Store release checklist”
I’ve written about building iOS applications with
Hudson Jenkins, but until recently there hasn’t been a convenient way of getting those applications to your testers. Of course the most important part of your build output will be the app bundle you send to Apple’s iTunes Connect web interface, but throughout your development cycle you’ll want to test your app. Sure you could build and deploy a debug build straight to your own personal device, but you get the most benefit from having other people beta test your app.
With recent releases of Xcode and the iOS SDK, Apple improved their AdHoc distribution support with two main enhancements:
- Mobile provisioning files can now be embedded in the App’s IPA itself, meaning you don’t have to maintain and update separate .mobileprovision files separately;
- A specially-formated manifest Plist file can be created that, when linked to properly, allows test devices to install new versions of your AdHoc app without needing to plug into a computer to sync the app using iTunes.
These improvements are huge, but require some changes to your build scripts and your Continuous Integration environment. I’d like to show you how to do this in your own installations, and show you some options for how to distribute your apps to your testers.