Adding Build Versions via Xcode

One of the things I was keen on setting up early in development was the automatic injection of a build number for our products.  Having a build number is vital when handing out early “pre release” versions of the app to testers for review.  During development, there are likely to be a number of builds and release candidates – and you’ll need a way to differentiate between them.

It turns out I wasn’t alone as a quick search on Google provided a wealth of possible options.


Apple provides a generic versioning build tool.  It provides a number of useful functions, like hooking directly into CVS or Subversion to commit modified code.  In addition, it automatically creates a CFBundleVersion key in your info.plist file.

By default, CFBundleVersion is 1.0 in the info.plist file.  But, there’s another key, CFBundleShortVersionString which can be used for this same purpose.  Thus, you could set the short version to “1.0” and let the agvtool set the CFBundleVersion key to the current build number.

If you automate your builds on a neutral machine, this technique is definitely something to consider.  It seems the most natural fit for generating a build number that can be referenced in an app.  There are a number of other folks who have tutorials and walkthroughs for exactly how to set this tool up for use in development:

Inner Exception

Chris Hanson’s Blog

Jamie Montgomerie’s Blog


While the agvtool has some definite benefits, it felt a bit “manual” to me.  Sure, you can hook it up as a post-build script or on a separate box that does nightly builds (or whatever) but I was looking for something else – like the revision number instead of a build number, per say, that was always updated without a ton of extra work.

Using the revision number from Subversion seemed an easier way to link the code state with the build number without the extra hassle of tagging or branching specifically for the purpose of sharing a build with testers or external stakeholders.  So, I turned my attention to script based solutions.

Luckily, there are a number of posts that describe how to do the exact same thing with a variety of scripting tools and languages.  Most hinge on creating a custom post-build step, then running either some Perl, Ruby, or shell script to substitute in the desired number into a plist file associated with your project.

Another choice in scripting tools is “PlistBuddy” which can read/write values to plists – but you’d need to wrap it in a shell script and at that point it’s debatable whether using Perl (or the shell) to perform the insertion isn’t just as easy.  PlistBuddy doesn’t solve the potential problem of parsing the revision number from Subversion either.

Adding something like this into your Xcode is trivial.  Under “Groups & Files” expand the Targets section and right-click the target to select Add –> New Build Phase –> New Run Script Phase.  A window will pop up where you can insert your own commands into the overall build.  Here’s some sample code from other folks:

Ruby – Jeff LaMarche, author of “Beginning iPhone Development.”

Git – Marcus Zarra.

Perl – Stackoverflow.

In the end, I took the route proposed by Daniel Jalkut on Red Sweater using Subversion with a couple minor modifications:

# Xcode auto-versioning script for Subversion
# by Axel Andersson, modified by Daniel Jalkut to add
# “–revision HEAD” to the svn info line, which allows
# the latest revision to always be used.

use strict;

die “$0: Must be run from Xcode” unless $ENV{“BUILT_PRODUCTS_DIR”};

# Get the current subversion revision number and use it to set the CFBundleVersion value
my $REV = `/usr/local/bin/svnversion -n ./`;

my $version = $REV;

# (Match the last group of digits and optional letter M/S):
($version =~ m/\d+[MS]*$/) && ($version = $&);

die “$0: No Subversion revision found” unless $version;

open(FH, “$INFO”) or die “$0: $INFO: $!”;
my $info = join(“”, <FH>);

$info =~ s/r0000/r$version/;
print $version;
print $INFO;

open(FH, “>$INFO”) or die “$0: $INFO: $!”;
print FH $info;

The major change from the original is that I write to a separate plist file (version) instead of Info.plist with a default key of “r0000” which is used for the substitution.  Really there’s not much difference and the choice of which scripting language is largely a personal choice for maintenance sake.

Leave a Reply

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