Search
davedelong's tweets
- @JayCarr it's in the prefs, under "Advanced" — 11 hours 23 min ago
- so that bug i was tracking down all afternoon wasn't actually my bug. silly xib using a wonky encoding :P — 14 hours 47 min ago
- @alesplin 5 pm Mountain Time, i think — 16 hours 50 min ago
- @JayCarr not yet... — 17 hours 20 min ago
- Software Engineering is the "[art of making] software accessible to those who do not know how it works." http://bit.ly/9cNqsF — 23 hours 23 min ago
- 1 of 477
- ››
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
Build number increment
Anonymous — Tue, 09/15/2009 - 01:26Thanks 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:58Thank 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.
That's it ... now it will auto-generate version numbers and version strings in the form #.#.#
Regards,
Robert.
Info.plist refresh issue ...
Anonymous — Tue, 10/13/2009 - 18:01Oh 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:22Thank 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:56This 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:45Well, the script I posted is modifying the
Info.plistfile 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 theInfo.plistfile toInfo.plist.template, check the template into my VCS, and then generate theInfo.plistfile in the script from the template, and compile using the generatedInfo.plist. That way your VCS can ignore theInfo.plistfile and it's often-changing build numbers, but you'd still have a checked-in version (the template).