Automatic Build Incrementation Technique for iOS Release

While in the development phase or live phase of the application, every iOS developer faced the problem for build version increment during upload build on TestFlight or iTunes 😕. 
Even the continuous delivery of the application is compulsory to stay relevant in the competitive market. During the continuous delivery mode, We need to constantly uploading the iOS build to TestFlight or iTunes to get the feedback of the people involved in application release 🤕. There isn’t any loss in upload the build again again as we have a proper build and versioning tool provided by Apple 👨‍💻.
In this post, we will be discussing the best techniques to automatically increase the build number in continuous delivery mode 😅.

What are release train, version numbers and build numbers?

Before moving to the discussion, we will see how the build number, version number and release train work when submitting the app on TestFlight or iTunes 🤔.
Apple provided the great documentation on build number and version number that every iOS developer must gone through.

Release Train

Build numbers provide a way to name each of the submissions you provide for a particular release, build numbers are in the incremental order and unique. The release train can have multiple builds with the different features, the collection of all of the builds that you provide for a particular version of your app is called that version’s ‘release train’.

Version Number

Version number of the application differentiate the application from the previous version of the application on TestFlight or iTunes. We always need to create a new version number for the every new application release. The legal version number would be like 1.0.0, 1.1.1, 3.0.2 e.t.c, but can not contain the later like xyz.1.0 it would be and illegal version number 🚫️.
The version number can not be reused, ⚠️ it MUST be the greater then the previous version number.

Build Number

Build numbers are the sub part of the version of the application. A single version number can have the multiple build numbers. However the build numbers also should bet the unique and greater then the previous build version with respect to the same version number.

Auto Build Incrementation Techniques

Well, as we already know 😃 about the release train, version numbers and build numbers.
So, There are few techniques in my knowledge that will help to automatically increase the build number of the application release.

1. Scripted Build Numbers

There is a way to use the script to increment the build number, generate some random number and increment the build number accordingly 😯. In details you can read here.


buildNumber=$(expr $(git rev-list $branch --count) - $(git rev-list HEAD..$branch --count))
echo "Updating build number to $buildNumber using branch '$branch'."
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${TARGET_BUILD_DIR}/${INFOPLIST_PATH}"
if [ -f "${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}.dSYM/Contents/Info.plist" ]; then
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}.dSYM/Contents/Info.plist"
  1. Put this script in a file in your repository (somewhere like /scripts/) with .sh extension
  2. In Xcode, create a Run Script build phase AFTER the Copy Bundle Resources phase
  3. In the Run Script, call path/to/ [branch] where [branch] is the branch you want the count based on. If not supplied, master is used.
    This will give a new build number whenever you archive your application to upload toTestFlight or iTunes.

2. PlistBuddy

We also can achieve this build number incrementation using the PlistBuddy tool, which is mainly used to dynamically update the plist file. You can read more about PlistBuddy here.


buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion "$PRODUCT_SETTINGS_PATH")
buildNumber=$(($buildNumber + 1))
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "$PRODUCT_SETTINGS_PATH"

We can easily use this script to increase the build numbers. This script update the Info.plist file ❗️.
If you are using any source control the you always need to make a commit back after the build upload.

3. agvtool

Apple provides a native command line tool to deal with the build and version numbers.
In order to enable agvtool, we need to make sure that we have Current Project Version and Versioning System properties are set correctly in Target Build Settings of the project.
Select the target build settings and search for “versioning” 🧐. 
Now, set Current Project Version to 1.
and select the Versioning System value to “Apple Generic”.
Next thing to verify, make sure that Info tab has Bundle versions and Bundle versions string 👍, default values are set probably to 1 for new project.
We can increment build number to next build number using the following command

$ xcrun agvtool next-version -all

As we execute this command from the CI server, it dynamically updates the Info.plist file same as the PlistBuddy which we need to commit back to the source control once the build uploaded. By using this we always need to update source control frequently from the CI server.
You can read more here about agvtool.

4. Fastlane Plugin

There is a third party called ‘Fastlane’ which also enables you to do the same thing. Fastlane have the actions to increment the build numbers as well as the version numbers.

Increment Version Number:
increment_version_number action can be used to increment the version number of the release.

bump_type: "major" # Automatically increment major version number

Increment Build Number:
increment_build_number action can be used to increment the version number of the release.

build_number: "2" # set a specific number, default automatically increment by one

Which one to use?

As of now, we have discussed 😀four different techniques to Automatic Build Incrementation for iOS Release. It’s bit tricky 😧 to select the technique that suits to you iOS application. All the discussed techniques will work fine if scripted and managed in a proper manner.
However, I would prefer the first one as it doesn’t require the changing source control repository and also not updating the Info.plist file frequently 😉.


During the continuous delivery mode of the iOS applications, automating the build and version numbers saves a lot of time 🤩. As we need to constantly uploading the iOS build to TestFlight or iTunes we don’t need to remember 🤔 to increase the build and version numbers.
Which strategy do you use for build incrementation? Please let me know if I missed anything 😊.

Thank you for reading, please hit the recommend icon if like this collection 😊 . Questions? Leave them in the comment.