This one is a relatively simple mechanism for automatic build numbers. This increments the build number every time a successful build is made in Xcode.

Step 1: Create a new Run Script

In the target setting, add a new Run Script after the Link Binary With Libraries. Change the shell to /usr/bin/perl -w and paste the following script:

# Auto increment version number from build common file

use strict;

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

# Get the current revision number and use it to set the CFBundleVersion value
open FH, "build.count" or die;
my $version = join("",);
close(FH);

++$version;
print "Build $versionn"; 

open FH, ">build.count" or die;
print FH $version;
close(FH);

$version = "1.0 ($version)";

# Update info.plist in build product. Use defaults command

my $INFO = "$ENV{BUILT_PRODUCTS_DIR}/$ENV{WRAPPER_NAME}/Info";
my @defaults = ( 'defaults', 'write', $INFO, 'CFBundleVersion', "'$version'" );
exec @defaults;

Note: If this is for a MacOS X application instead of an iPhone application, then the third to last line should be:

my $INFO = "$ENV{BUILT_PRODUCTS_DIR}/$ENV{WRAPPER_NAME}/Contents/Info";

Step 2: Create the Build Count file.

Note that this Perl script pulls the version number from a file “build.count” which is at the same directory level as the project file. You should create a file containing the single character “0”.

Step 3: Build

Now you can test to make sure that the CFBundleVersion setting in the Info file is updated to “1.0 (1)”, “1.0 (2)”, etc. (The “1.0 ” part is set by the build script; change there to update the major/minor build numbers, or prefix the build with anything you want.)

This works by incrementing the build number in the build.count file, then using the defaults command-line tool (‘man defaults’ for more) to update the info.plist file after it is copied into the executable bundle.

The original concept came from Red Sweater Blog: Automatic Build Sub-Versioning in Xcode. However, in my case I wanted to do the build version count between check-ins, and we are currently using GIT. (But that’s another horror story.)