iPhone Dev Tip #3: Sanity From Automated Builds

It’s been hellishly busy as of late, as I’m knee deep in Tilt to Live HD.  Now on with my quick blurb:

This tip is kind of a “duh” much in the same way version control software is for most developers. The thing is I still meet a lot of developers who don’t use any form of version control. And automated builds simply weren’t even in my own tool set initially. Mostly because my build steps for projects never scaled to the complexity required to build like an iPhone application. And it wasn’t even complex. It was just a matter of remembering which command line parameters to use and which provisioning file to include and to zip it up all tidy and neat.

Now with XCode’s build and archive command a lot of this is simplified with a GUI, but that’s the crux of it. It still requires you to go through several clicks to send a build out.

My setup is pretty simple by using a makefile and the xcodebuild commandline tool. xcodebuild just allows you to build projects from a commandline very easily. Mix that with a few basic unix commands, agvtool, SVN and you have a primitive but simple build pipeline that you can execute with a single command and not thing about anything else. I’ve been using it throughout Tilt to Live’s development and haven’t had a need to really look elsewhere since it accommodates exactly what I need to do: not screw up build submissions or beta builds for testers.

Over the months my makefile has grown to include a few other ‘targets’ for faster iteration during gameplay tweaking, but the 3 essential ones were:

  • build – this just builds my app for ad-hoc distribution into a zipfile named ‘appname_versionnumber.zip’ and a debug symbols file next to it. It then moves these two into a builds folder where I keep all my builds. It works in conjunction with the agvtool so that it increments the build number and submits the new version to SVN.
  • appstore – This target does the same as ‘build’ except it builds with the app store distribution settings.
  • clean – just wipes all my intermediate object files and build temp folders if I want to build from scratch

Below is just a snippet from my current build target. It builds the projects, moves the app files and provisioning files into the current directory. Zips those two up and copies them to a build directory with the debug symbols.

[code]
build:
cd $(PROJDIR) ; agvtool -usesvn next-version -all
xcodebuild -project $(PROJ) -target Tilt_To_Live_HD -configuration Distribution

#move app files into build directory
cp -R $(DISTRODIR)/$(APPFILENAME) $(APPFILENAME)
cp $(PROVISION) $(PROVFILENAME)

#zip up the app file and move debug symbols
zip -r -y -q “$(BUILDDIR)/tilttolivehd_`cd $(PROJDIR) ; agvtool vers -terse`.zip” $(APPFILENAME) $(PROVFILENAME)
rm -rf $(APPFILENAME)
rm -rf $(PROVFILENAME)
cp -R $(DISTRODIR)/$(DEBUGSYMBOLS) “$(BUILDDIR)/tilttolivehd_`cd $(PROJDIR) ; agvtool vers -terse`.dSYM”
[/code]

I wonder if the xcodebuild tool has some commands for automating the ‘build and archive’ command. That would simplify my targets even more.

4 comments

  1. I guess I’m a bit weird in that I almost like the fact that it takes a bit of work to do a build, that way it really forces me to make sure I’m doing it right the first time.

    I’m currently using this little “Packager” script by Aral Balkan, which you can get here: http://aralbalkan.com/2590

    It does a somewhat similar thing, but without the commiting to SVN and all that. It basically just makes a folder with the new ipa, provisioning profile and the debug symbols. It has the added bonus of not allowing you to make two builds with the same version number(a common mistake with ad-hoc builds).

  2. If you have a build automation, you can integrate it with continuous integration system (like http://hudson-ci.org/ ) — it makes the process a little bit cleaner and faster (i.e. distribution of ad-hoc builds via web interface).

Leave a Reply

Your email address will not be published. Required fields are marked *