How to auto increment Xcode project build version numbers

04th Jul, 2017 | xcode

One slight niggle to be aware of when using Xcode projects is the bundle version, stored in the target's Info.plist file.

During normal development this numeric value has little significance. However when you start uploading builds elsewhere it is vital as it represents the unique identifier for that build. If this remains at the default '1' your build will either be rejected or it may be ambiguous to which build is which.

Avoid forgetting to increment the Xcode project build version number!

The answer is to increment the bundle version manually before uploading a build somewhere, however this is something that can be easily forgotten.

My preferred solution is to add a tiny build script to my Xcode projects that will increment the bundle version for me every time the project is compiled. A nice side effect of this is I get a vague sense of how much work has gone into a project simply by looking at the bundle version.

Of course the "Bundle version string, short" value must still be set manually but this is only done when preparing a release.

Adding the automated script

  • In your Xcode target project settings select the "Build phases" tab.
  • Click the "+" button add select "New Run Script Phase"
  • In the script area paste this tiny script which will increment the bundle version every time the project is built:
# This script takes the build number from the release target plist, increments and then saves back
bN=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${PRODUCT_SETTINGS_PATH}")
bN=$(($bN + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $bN" "${PRODUCT_SETTINGS_PATH}"

That's it!

Finding more about Xcode environment variables

The script uses the "PRODUCT_SETTINGS_PATH" Xcode environment variable to locate the Info.plist file. I wasn't aware there was such a variable, which I found by cheating :-)

I created a quick test build script to capture the environment variables available during the build phase by creating a build script similar to above.

This time I used:


env > /tmp/Xcode_env.txt

After a quick build examining the /tmp/Xcode_env.txt file revealed all sorts of goodies. I'm sure there are docs with all these in but in this case this was quicker!