If you ever need to analyze a crash report you will need not just the application binary but also the .dSYM symbol file generated at build time. It is therefore a very good idea to save these two files anytime you produce a build for distribution. This applies to builds uploaded to the App Store or Ad Hoc builds distributed to beta testers.
There is a lot of good advice around on how to automate the saving of these files to your version control repository. However it seems that some improvements made to the Organizer in Xcode 3.2.2 could offer an alternate workflow. There is now a new option in the Xcode Build menu to “Build and Archive”. Building with this option drops you into the Organizer where a number of changes have been made:
The Archived Applications item under the iPhone Development section shows all archived builds (those produced by the Build and Archive command). The builds are listed by timestamp and some basic application information such as the bundle identifier and version are displayed.
Somewhat more useful are the options to validate, share or submit your application. This is not an indication that Apple wants you to publish your applications to Facebook but an easy way to interact with iTunesConnect for publishing your app to the App Store.
The documentation for the latest release of Xcode still seems to be missing in action but the basic functionality is fairly obvious. The validate application option asks you for your iTunesConnect username and password and then validates the application against an application you have already added to iTunesConnect. The Share Application option allows you to resign the application for Ad-Hoc distribution and finally Submit Application to iTunesConnect does exactly that removing the need to use the separate application loader.
Anyway back to the problem of saving the application binary and .dSYM file for each distribution build. When you use the Build and Archive command the application binary, the
.dSYM file and a
.ipa file are saved in a directory under
~/Library/MobileDevice/Archived Applications. What I like about this is that I can be sure that I have saved the versions that I then submit to the App Store. The disadvantage is that the files are archived to a directory that is not under version control.
The extra manual step to copy the files to a directory that is controlled and then tag and commit the build is a disadvantage but since this also coincides with a number of manual steps such as incrementing version numbers ready for the next release it may not be too big a hardship. Time will tell…