With the recent release of Xcode there are now some really great tools for archiving and distributing builds. How that works is beyond this post, but you can find more at Apple’s Dev Center and Erica Sadun’s devsugar article “A better way to share ad-hoc builds”.
While these tools are great for a single developer, or a very small group that has a single person responsible for builds, they are far from ideal for large groups. At my day job we are a pretty large outfit. During the course of the day engineers will make builds for themselves, but in the end we have a build system where all official builds come from. Depending on the project there are anywhere from one to four configurations that get built for every target when there are new commits. Doing that by hand would be time consuming and a waste of a human resource. We have a build system to handle all of this automatically for us (that can be the focus of another post later).
One of our core philosophies is that the app we test is the one that must be shipped to Apple for release. Testing the exact same binary we’re going to be shipping for sale gives us a high degree of confidence in what we’re shipping. Why would you ever ship bits that you haven’t tested? You shouldn’t. If we built separate ad hoc and app store binaries and only tested the ad hoc we’d be doing our customers a disservice. Fortunately there is a way around this, and you only need two builds and three provisioning profiles to cover all your bases.
In the Dev Portal you’ll want to generate the three profiles to be used. When you’re doing this consistency in naming is key. I like to label all my files (now that I’ve learned) so I can target them easier in the future. The labeling scheme I use is:
- Development profile: SomeApp_development.mobileprovision
- Ad Hoc profile: SomeApp_ad_hoc.mobileprovision
- Distribution profile: SomeApp_app_store.mobileprovision
Fig 1: Don’t forget to set the bundle identifier to the same as your AppID and profiles.
A lot of people start development with the wildcard development profile for their developer account. That’s fine for getting off the ground with a minimum of fuss, but I really recommend getting into the practice of signing with app-specific profiles as soon as possible. The major reason is you’re signing against a profile that’s targeted at your bundle identifier and you’ll know immediately if it is incorrect. Another thing you want to do is mimic in your development environment as close a conditions as possible to what you’re going to be submitting. Running on a wildcard is fine and dandy, but it’s not anything like making sure you’re app is ready to submit to Apple, especially if you’re going to be using In-App Purchasing and Push Notifications (since IAP and Push don’t work on wildcard App IDs).
With this system you only have two build configurations you’ll need. You may, of course, want more to fine tune things, but really two is plenty to get where you’re going. The first configuration we’ll call Debug (the default name in Xcode). This will be a build that is signed with the development profile we created above. We’re not so worried about this configuration, it’s pretty standard and should be used for your iterative builds that you’re going to test on your devices.
Fig 2: Set the Debug configuration to the development profile.
The second configuration we’ll call Release (again, the default name in Xcode). From this one we’ll build optimized builds that can be packaged and sent to either our QA group, beta testers, or Apple to put into the App Store. From this build we’ll generate ad hoc releases and app store binaries. We will not, however, ever have to change the code signing setup once we’ve got it in place. That’s right, we’ll sign with one profile and distribute two different times. I didn’t believe it at first myself, but now that I’ve seen it I love the simplicity of building apps this way.
Fig 3: Set the Release configuration to the app store profile.
In your Release configuration set the code signing to use the SomeApp_app_store.mobileprovision. That’s it. Build as many times as you like, but you only ever code sign with the app store profile you created. When it comes time for you to send a build to beta testers you take the SomeApp.app bundle and the ad hoc profile and zip them into an archive (You can make an IPA file like iTunes does, but I don’t have any experience to share on that right now). The testers then install both files via iTunes, Xcode, or iPhone Configuration Utility and are able to run it on their devices. After a clean bill of health from testing you can then take that exact same SomeApp.app bundle and zip it and submit it to Apple for review. Simple. Easy. Less headaches.