How can I display the application version revision in my application's settings bundle?

Panagiotis Korros picture Panagiotis Korros · May 18, 2009 · Viewed 52.7k times · Source

I would like to include the application version and internal revision, something like 1.0.1 (r1243), in my application's settings bundle.

The Root.plist file contains a fragment like this...

     <dict>
        <key>Type</key>
        <string>PSTitleValueSpecifier</string>
        <key>Title</key>
        <string>Version</string>
        <key>Key</key>
        <string>version_preference</string>
        <key>DefaultValue</key>
        <string>VersionValue</string>
        <key>Values</key>
        <array>
            <string>VersionValue</string>
        </array>
        <key>Titles</key>
        <array>
            <string>VersionValue</string>
        </array>
    </dict>

and I would like to replace the "VersionValue" string at build time.

I have a script that can extract the version number from my repository, what I need is a way to process (pre-process) the Root.plist file, at build time, and replace the revision number without affecting the source file.

Answer

Quinn Taylor picture Quinn Taylor · Jun 30, 2009

There is another solution that can be much simpler than either of the previous answers. Apple bundles a command-line tool called PlistBuddy inside most of its installers, and has included it in Leopard at /usr/libexec/PlistBuddy.

Since you want to replace VersionValue, assuming you have the version value extracted into $newVersion, you could use this command:

/usr/libexec/PlistBuddy -c "Set :VersionValue $newVersion" /path/to/Root.plist

No need to fiddle with sed or regular expressions, this approach is quite straightforward. See the man page for detailed instructions. You can use PlistBuddy to add, remove, or modify any entry in a property list. For example, a friend of mine blogged about incrementing build numbers in Xcode using PlistBuddy.

Note: If you supply just the path to the plist, PlistBuddy enters interactive mode, so you can issue multiple commands before deciding to save changes. I definitely recommend doing this before plopping it in your build script.