Incrementing Build Numbers in Xcode

Search

davedelong's tweets

@mdjensen it depends on the db system. %% might work. — 3 hours 26 min ago
Only have one more level on #starcraft2. I'll save it for tomorrow — 4 hours 36 min ago
dumb dumb dumb dumb duuuuuuuummmmmmmb http://www.heyuguys.co.uk/2010/07/28/titanic-2-trailer-no-this-is-not-a-... — 1 day 13 hours ago
@jergason they screwed up my order, and their help email address never sent anything but automated responses — 1 day 14 hours ago
Fed up with @gamestop's terrible customer service. Cancelled my order for #starcraft2 and will buy it from anyone but them — 1 day 14 hours ago

Incrementing Build Numbers in Xcode

davedelong — Wed, 04/15/2009 - 12:01

I admit, I'm a sucker for numbers. When I release a project, it'd be kind of cool to know how many times I've built it. With that in mind, and with a good deal of help from my friend Quinn and a couple of online tutorials, I was able to come up with a neat little script that can do just that.

Here's what you need to do:

Select the target you're working with, and add a new "Run Script Phase" to it

Paste the following code into the script box:

#!/bin/bash
buildNumber=$(/usr/libexec/PlistBuddy -c "Print DDBuildNumber" Info.plist)
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :DDBuildNumber $buildNumber" Info.plist

Compile with impunity

The idea is simple: It uses your project's Info.plist file to store an integer value under the key "DDBuildNumber". Every time you build, it grabs that number, increments it, and saves it back to the plist.

A caveat: It seems like Xcode is caching Info.plist, so you may not see the change reflected immediately in Xcode. However, if you open Info.plist from the Finder (or just Quick Look it), you'll see that the number has changed.

Cheers!

Dave

Add new comment

Build number increment

Anonymous — Tue, 09/15/2009 - 01:26

Thanks for the script, especially for the use of PlistBuddy.
Seems like the best tool for hacking the info.plist.
I had been using sed and defaults(1) but this is much cleaner.
defaults(1) also has a nasty habit of modifying the target file permissions to 600 (on 10.6 anyway).

Jonathan Mitchell

www.mugginsoft.com

Extended the concept ...

Anonymous — Tue, 10/13/2009 - 17:58

Thank you! Brilliant!

I've extended this concept a bit to make it easier to have auto-incrementing build numbers and a version number available. A key factor for me was simplicity and ease of management for resetting the build numbers or incrementing version numbers from a single location.

I've added a 'prefix' and the same auto-increment numbering, and combined this to ensure that each build generates a unique version number which is easily managed.

Create 2 keys:
CFBuildVersion - Put any 'prefix' you would like to have in here (like "1.0")
CFBuildNumber - Start your Build Numbering with 0 (Reset when you change BuildVersion)

Also, the latest XCode projects use a ${PROJECT_NAME}-Info.plist file instead, so added that as a pseudo-parameter.

#!/bin/bash
# Auto Increment Version Script
buildPlist="Project-Info.plist"
buildVersion=$(/usr/libexec/PlistBuddy -c "Print CFBuildVersion" $buildPlist)
buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBuildNumber" $buildPlist)
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBuildNumber $buildNumber" $buildPlist
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildVersion.$buildNumber" $buildPlist
/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString $buildVersion.$buildNumber" $buildPlist

That's it ... now it will auto-generate version numbers and version strings in the form #.#.#

Regards,
Robert.

Is it still suppose to work in Xcode 3.2.3 ?

Anonymous — Tue, 04/13/2010 - 09:50

Hello,

When I found this page I was pretty sure my problems were over but ...
I did all the steps in this page but the build stage in Xcode saus /bin/sh runscript stage failed
(of course i removed the /bin/sh of the line above to replace with /bin/bash)

The problem I have is that he is not finding the keys ... I create them so they are in but somehow not "identified"

Any help/clue would be appreciated ;)

Thanks

GH From Paris

Expanded to work with the latest Xcode

Anonymous — Wed, 05/19/2010 - 16:49

In the New build phase run script Info window, put this line:

./Resources/plistVersionIncrement

In the Resources directory of your project (assuming you have a Resources directory, if not, create one)
put this script called: "plistVersionIncrement"

#!/bin/bash
#
# @(#)	Increment the version number in the project plist.
#		Note:	The project plist could be in directory
#				"Resources" or the project root.
#				Personally, I avoid clutter in the project root.
#		Enjoy! xaos@xm5design.com
#
PROJECTMAIN=$(pwd)
PROJECT_NAME=$(basename "${PROJECTMAIN}")
#
if [[ -f "${PROJECTMAIN}/Resources/${PROJECT_NAME}-Info.plist" ]]
then
	buildPlist="${PROJECTMAIN}/Resources/${PROJECT_NAME}-Info.plist"
elif [[ -f "${PROJECTMAIN}/${PROJECT_NAME}-Info.plist" ]]
then
	buildPlist="${PROJECTMAIN}/${PROJECT_NAME}-Info.plist"
else
	echo -e "Can't find the plist: ${PROJECT_NAME}-Info.plist"
	exit 1
fi
#
buildVersion=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${buildPlist}" 2>/dev/null)
if [[ "${buildVersion}" = "" ]]
then
	echo -e "\"${buildPlist}\" does not contain key: \"CFBundleVersion\""
	exit 1
fi
IFS='.'
set $buildVersion
MAJOR_VERSION="${1}.${2}.${3}"
MINOR_VERSION="${4}"
buildNumber=$(($MINOR_VERSION + 1))
buildNewVersion="${MAJOR_VERSION}.${buildNumber}"
echo -e "${PROJECT_NAME}: Old version number: ${buildVersion} New Version Number: ${buildNewVersion}"
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion ${buildNewVersion}" "${buildPlist}"

This works very well with Xcode V3.2.2

Thank you for getting me started with this script.

Xaos (xaos@xm5design.com)

XM5 Design Inc.

Expanded to Root.plist

Anonymous — Thu, 07/01/2010 - 08:05

Thanks! This was such a time-saver to find. I made a slight modification to also write the updated version number to my Settings bundle.

#!/bin/bash
# Auto Increment Version Script
# Found here: <a href="http://davedelong.com/blog/2009/04/15/incrementing-build-numbers-xcode<br />
#<br />
#" title="http://davedelong.com/blog/2009/04/15/incrementing-build-numbers-xcode<br />
#<br />
#">http://davedelong.com/blog/2009/04/15/incrementing-build-numbers-xcode<br />
#<br />
#</a> Set the paths to the build and settings Plist
buildPlist="${PRODUCT_NAME}-Info.plist"
settingsPlist="Settings.bundle/Root.plist"
 
# Get the existing buildVersion and buildNumber values from the buildPlist
buildVersion=$(/usr/libexec/PlistBuddy -c "Print CFBuildVersion" $buildPlist)
buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBuildNumber" $buildPlist)
 
# Increment the buildNumber
buildNumber=$(($buildNumber + 1))
 
# Set the version numbers in the buildPlist
/usr/libexec/PlistBuddy -c "Set :CFBuildNumber $buildNumber" $buildPlist
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildVersion.$buildNumber" $buildPlist
/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString $buildVersion.$buildNumber" $buildPlist
 
# Set the version numbers in the settingsPlist (Your path to the key you store your version number may vary, mine is in item 0)
/usr/libexec/PlistBuddy -c "Set :PreferenceSpecifiers:0:DefaultValue $buildVersion.$buildNumber" $settingsPlist

Info.plist refresh issue ...

Anonymous — Tue, 10/13/2009 - 18:01

Oh yeah, XCode does cache the plist file, but it's easy to view the updates/changes to verify the script operation.

Close the window (Command - Shift - W), and re-open it. Xcode will display the updated values.

Regards,
Robert.

Thank you both, Dave and

Anonymous — Mon, 10/19/2009 - 02:22

Thank you both, Dave and Robert, this post is exactly what I was looking for, and the script provided is flawless.

Distributed?

Anonymous — Wed, 02/03/2010 - 08:56

This works great if you're a one man team. Any ideas on how to manage this on a distributed system? I'd like to avoid checking in the plist every time I build.

Use a template file

davedelong — Thu, 02/04/2010 - 10:45

Well, the script I posted is modifying the Info.plist file in-place, which means that your VCS is going to see that it has changed. Obviously, you don't want your VCS to ignore the file, because there occasionally are legitimate changes to the file you want saved. What I'd probably do in this case is use move the Info.plist file to Info.plist.template, check the template into my VCS, and then generate the Info.plist file in the script from the template, and compile using the generated Info.plist. That way your VCS can ignore the Info.plist file and it's often-changing build numbers, but you'd still have a checked-in version (the template).

Latest XCode project update

Anonymous — Thu, 05/27/2010 - 17:47

Hi there, thnx a lot for the script, is very neat, here's a little update I made to handle some new project settings:

buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" ${PRODUCT_NAME}-Info.plist)
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" ${PRODUCT_NAME}-Info.plist

that's it, pretty much the same and is working like a charm again