I am trying to figure out how to have the Bundle version number increment automatically in my Xcode 4 project (for ad-hoc and release builds). I found some scripts online that purport to do this but I am unsure of whether to place them in the "Pre-actions" or "Post-actions". I also am unsure what value I should place in the plist; a number that the script will then change or a variable?

All the options that I have tried thus far do not seem to work so any help would be greatly appreciated.

Sorry not to mentioned that Pre-actions/Post-actions are not part of the build system. If you want to update the build number every time a new build process is kicked off, run your script from Post-action. You can also have a look into following steps (at best it might be a workaround) 1. cmd + , 2. Select "Behaviors" tab 3. Select "Build succeeds" item from left pane 3.1. Check on "Run" option from right pane and choose your script that will increase build number. This time buildNumber will increase if your build succeed. Note: preferences are applicable for all your Xcode projects.
– LearnerJun 18 '11 at 8:25

8 Answers
8

#!/bin/sh
# Auto Increment Version Script
# set CFBundleVersion to 1.0.1 first!!!
# the perl regex splits out the last part of a build number (ie: 1.1.1) and increments it by one
# if you have a build number that is more than 3 components, add a '\.\d+' into the first part of the regex.
buildPlist=${INFOPLIST_FILE}
newVersion=`/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "$buildPlist" | /usr/bin/perl -pe 's/(\d+\.\d+\.)(\d+)/$1.($2+1)/eg'`
#echo $newVersion;
/usr/libexec/PListBuddy -c "Set :CFBundleVersion $newVersion" "$buildPlist"

thanks for nice utility! , you can actually just put it into root of project and with shell /bin/sh , call it as "$SRCROOT/autoversion.sh" (with quotes) , so the project is portable
– PetrVJul 23 '13 at 9:45

Working on complex builds with apps, libraries, and SDKs you have to be able to coordinate not merely build numbers per project, but build number compatibility.

You can make a build management header that is effectively a text file with build iteration numbers (or versioning info i.e. beta, dev, rel) and import it through the xcconfig import chain per project.

At that point you can have a target build script step that will embed your build/versioning info. This is also best done by putting holding text in your plist and running PlistBuddy on your derived file/built file sections. (This way your source control changes are minimal)

If you can write a build execution script that does the necessary build number twiddling (or better yet, use a system like bamboo which creates the file for you), you can keep that separate from your code. Granted, if you need to do it and keep track, you may have to check in the changed build number to allow it to increment.

I've been able as a result of this to maintain build numbers along the line of:
2.0.3 b34 (3473) Where we have a build number and an SVN checkout build point.
(Please no git hazing, I'm old school)

Pre/Post actions are more for Uber notifications or processes:
Email that the build started/failed/ etc
Copy the done project to the done project server.