4
votes

I'm creating distribution build directly from titanium studio to upload on iTunes Connect for Apple Testflight prerelease testing. My current app version is 1.1.1 and build number is automatically set by titanium studio to 1.1.1.

On Xcode generally the Prerelease build number (CFBundleVersion) is maintained as Integer by most developers which is a very convenient to increase by 1 each time before uploading on iTunes. From titanium studio which is not possible!

In tiapp.xml I set this

<ios>
    <plist>
        <dict>
            <key>CFBundleShortVersionString</key>
            <string>1.1.1</string>
            <key>CFBundleVersion</key>
            <string>10</string>
        </dict>
    </plist>
</ios>

After I run from Titanium Studio the generated info.plist under build folder becomes

<ios>
    <plist>
        <dict>
            <key>CFBundleShortVersionString</key>
            <string>1.1.1</string>
            <key>CFBundleVersion</key>
            <string>1.1.1</string>
        </dict>
    </plist>
</ios>

I know in appcelerator documentation they've already mentioned this, CFBundleVersion and CFBundleShortVersionString will become the same from <version> tag value in generated info.plist.

So the only way for now to use Apple Testflight for Ti app is to increase the app version (CFBundleShortVersionString) instead of build# each time it's uploaded on iTunes Connect which is definitely not a good way. From Xcode I can change the Build # but not all Ti apps would archive from xcode due to some modules and other issues.

There are lots of posts about this issue on appcelerator community but no acceptable solution yet. Has anyone got a working solution to change/increase the build# directly from Titanium Studio during creating distribution builds?

Thanks in advance.

3

3 Answers

11
votes

What i have found with the new iTunes/Testflight is it only regards the 1st 3 elements as the version number (e.g. 1.0.0) adding a 4th element to the this causes iTunesConnect/testflight to treat it as a build version for the same version (e.g. 1.0.0.1)

this has allowed me create a version 1.0.0 on itunesconnect and a subsequent upload for 1.0.0.1 under the same version just changed the version tag inside the tiap.xml

2
votes
  grunt.registerTask('tiapp', function() {
    var tiapp = require('tiapp.xml').load();
    var version = tiapp.version.split('.');
    tiapp.version = version[0] + '.' + version[1] + '.' + (parseInt(version[2], 10) + 1);
    tiapp.write();
    grunt.log.writeln(require('util').format('Bumped version to: %s', tiapp.version));
  });

see complete gist on using Grunt with titanium here https://gist.github.com/FokkeZB/4754f93f8b325156c33c

more details here http://tonylukasavage.com/blog/2014/01/23/automating-appcelerator-tasks-with-grunt-titanium-and-grunt-alloy/

1
votes

In my native Xcode project I use two small shell scripts in my Build Phases. This should also work for any other build process.

First:

if [ ${CONFIGURATION} == "Debug" ]; then
buildNumber=-1
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"
else
buildNumber=$(git rev-list HEAD | wc -l | tr -d ' ')
flag=""
if [ ! ${CONFIGURATION} == "Release" ]; then
flag="b"
fi;
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber$flag" "${PROJECT_DIR}/${INFOPLIST_FILE}"
fi;

Then at the end of the build process a quick reset to build number -1 (my default):

# reset the build number to the default -1 to prevent issues in git 
commits
buildNumber=-1
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"

These scripts set the build number to the number of git commits (feel free to use your build scheme here), builds the project and resets it to the default build number. The reset prevents a constant change in the info.plist file.

The CFBundleShortVersionString is handled manually because automating semantic versioning feels wrong to me.