Xcode 3.2: Build and Archive

One aspect of iPhone development that I'm no big fan of is ad hoc distribution. In Xcode 3.2, Apple added a new feature to Xcode that makes ad hoc distribution more than a fair bit better. But, for the first few weeks of using Xcode 3.2, I didn't even notice this item. I know many of you probably have, but I've talked to enough people that also missed it, that I figured it's worth a short post.

This new item lives under the Build menu, but frankly, I don't use menus much in Xcode. I use a very custom set of key bindings and have all my regular tasks' key commands memorized. The new option is called Build and Archive.

I still wish Apple would get rid of the whole process, but it's unlikely they will in the near future. In light of the situation, this makes life much, much better. It's a pretty good compromise between Apple's desires and the needs of developers, all in all.

Build and Archive builds your application, code signs it, and stores the application folder along with its symbols file (which you need to decode crash logs generated by ad hoc or release builds). Xcode's Organizer window gives you ready access to any previous build, and lets you e-mail an ad hoc build packaged up as an .ipa file with the mobile provisioning profile you compiled with embedded right into the application. This allows your clients or tester to simply drag the generated .ipa file into iTunes. The organizer will even generate an e-mail with the .iap embedded in it.

As part of Build and Archive, Xcode checks your application to make sure it's code signed and provisioned properly. It may also (depending on your project settings) automatically run the new Validate feature that checks to make sure your application is valid for app store submission. This is the same check that the app review team will run on your app before actually looking at it. The details of what Validate checks are not documented, but in general terms, it will make sure everything is okay and that you haven't used anything you shouldn't have used. It's not a guarantee that your app won't get rejected because there's still the manual review for content and HIG, but if your app passes validation, that's one less possible obstacle between you and the app store. In other words, make sure you validate your apps before submitting them.

One thing to note, however, is that when you use Validate for ad hoc builds instead of building for submission to the app store (and I recommend that you do so that you find problems before testing rather than after), your app may fail one of the Validate checks. If you get this warning message when using either Build and Archive or Build and Validate with an ad hoc build:

warning: Application failed codesign verification. The signature was invalid, or it was not signed with an Apple submission certificate. (-19011)

You might be fine (assuming you received no other warnings or errors). The difficult thing is that this warning can be generated by more than one specific problem, so there's no way to know for sure whether this needs to be addressed other than to try and install the generated .ipa file on a non-development phone. You may (will?) get this warning with ad hoc builds even if the build is fine because you don't use an "Apple submission certificate" for ad hoc builds.

One of the best things you can do is to have a second iPhone or iPod touch that's not used for development (ever) that you can use to test ad hoc distributions. Even a second-hand, cheap iPod touch is sufficient since all you're testing is that the install works If you do this, make sure you add the UDID of this unit to your ad hoc distribution profiles, but not to your development profile.

When you see this warning with Validate when building using an Ad Hoc Distribution configuration, don't panic, but do try and install it on a machine that doesn't have your development profile installed before sending it to a tester or client.