I'm using this as a build phase in my project:
export PLISTBUDDY="/usr/libexec/PlistBuddy"
export INFO="${CODESIGNING_FOLDER_PATH}/Info.plist"
export RXREVISION=`git describe --tags | perl -pi -E "s/[^-]+\-([^-]+).*/\1/"`
export RXVERSION=`git describe --tags | perl -pi -E "s/([^-]+)\-[^-]+.*/\1/"`
$PLISTBUDDY $INFO -c "add CFBundleVersion string $RXREVISION"
$PLISTBUDDY $INFO -c "set :CFBundleVersion $RXREVISION"
$PLISTBUDDY $INFO -c "add CFBundleShortVersionString string $RXVERSION"
$PLISTBUDDY $INFO -c "set :CFBundleShortVersionString $RXVERSION"
This works perfectly for updating the build revision in the built application's Info.plist, and it doesn't mutate my source tree.
I have tried putting my Update Version script both at the end and also before the link phase. Either way, it's able to affect changes to the built application, but the dSYM is built from the original source tree.
This mismatch of version numbers between the built app and the built dSYM is a problem. (HockeyApp throws an error here.)
If I update the Info.plist in my source tree, I need to deal with it changing. Which leaves me two options that I can see:
How can I get the version in the dSYM updating automatically, too, without having to deal with the Info.plist in my source tree changing every build?
Also, tangentially: How do I see the version in the dSYM?
The accepted answer is correct, but doesn't give the actual details on how to modify the plist for the dsym. Adding the following lines to the build script modifies the plist in the dsym:
cd "$BUILT_PRODUCTS_DIR/$PRODUCT_NAME.app.dSYM/Contents"
$PLISTBUDDY -c "Set CFBundleVersion $RXREVISION" Info.plist
Here’s the full script for the “Set CFBundleVersion from git” build phase I’m using:
APP_INFO_PLIST="${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
DSYM_INFO_PLIST="${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}/Contents/Info.plist"
BUILD_NUMBER=`git rev-list HEAD --count`
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $BUILD_NUMBER" "$APP_INFO_PLIST"
if [ -f "$DSYM_INFO_PLIST" ] ; then
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $BUILD_NUMBER" "$DSYM_INFO_PLIST"
fi
(Note it must run after “Copy Bundle Resources” in Xcode 6+. In Xcode 10's new build system, make sure to specify the Info.plist file as part of its input files.)
The dSYM package also has an info.plist in the root folder with similar values. You could probably modify that too in a similar way.
Another option is to define the version number in an extra .xcconfig
file and include the version number from the info.plist into it, see here.
You could then also decide which kind of versioning you want or release or test builds, by using multiple independent info.plist
files and referencing to different .xcconfig
files in the build settings and don't include the one for test builds under source control.
In general I would suggest to do commits for every version change, since this makes the code really reproducible and also uniquely identify it in the source control system.
Apart from that, Apple specifies to set CFBundleVersion
to a "monotonically increased string, comprised of one or more period-separated integers", see here. CFBundleShortVersionString
is your marketing version, e.g. your goal is to work on version 3.0
.
So how about doing the following for a release build: Update CFBundleVersion
with the new build number and CFBundleShortVersion
with the new marketing version like 3.0 Beta 1
and commit both of them and then tag that commit for release. Version numbers are part of your source like any other meta data, especially if the version number are also used to trigger specific code for compatibility, database upgrades or other things (which is often done).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With