DevOps and Continuous Delivery practices enable continuous builds deployed to our internal or beta testing platform. It's essential to manage the version and build numbers of iOS apps. As a best DevOps practice, iOS teams should be frequently releasing a new version, i.e. marketing version, to the App Store, as well as making multiple builds for each version before submitting an app to the App Store. The release might have different builds with different features. It's very important to manage the build numbers as well as version numbers of iOS apps in order to make sure we are shipping the right version of the build to the App Store. In this post, we will see how to use the
agvtool command line utility to manage the version and build number of our iOS apps.
Version and Build Numbers
Before diving into agvtool, let's understand the version and build number of iOS apps.
Basically, the version number is the marketing number for the app, which is the number shown to your application’s users. It identifies a released version of your application. It is stored in your application’s Info.plist as
CFBundleShortVersionString (Bundle versions string, short).
The build number identifies an unreleased or released version of your application. It is stored in your application’s Info.plist as
CFBundleVersion (Bundle version) . We can make multiple builds for a specific version.
agvtool is a command-line tool comes that allows you to automatically increment these numbers to the next highest number or to a specific number. This tool comes with Xcode command line tools and can be directly accessed from the
$ xcrun agvtool $ xcrun -find agvtool
You can read about the options available with the tool from its documentation page.
$ man agvtool
This will show all the commands that come with agvtool.
Now we will see how to use agvtool on a real iOS app. In order to do that, let's create a single-view iOS app called "agvtool-Demo" in Xcode. There are a couple of things we need to ensure before we start using agvtool from the command line:
Enable the agvtool and versioning system
Disable/Enable Source Control Setup
We will see how to set it up in Xcode.
In order to enable agvtool, we need to make sure we have Current Project Version and Versioning System properties set correctly in the target build settings. 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 is that make sure the Info tab has Bundle versions and Bundle versions string, short values are probably set to 1 for the new project.
Disable/Enable Source Control (CVS, SVN)
The agvtool will make changes in some files inside the Xcode project when it changes the version or build number. We can commit those changes to source control if we use CVS or SVN. No need to worry about these settings if you are not using SVN or CVS. By default committing the changes to CVS or SVN are ON, however, we can disable that setting by running following commands:
$ defaults write agvtool SVNEnabled NO $ defaults write agvtool CVSEnabled NO
Command Line agvtool
Now, we have done all the setup to use agvtool from the command line. We will see a few useful commands that we use frequently. We need to run the agvtool command from the root of the project where your .xcodeproj file is located.
View Existing Values
- Version Number
We can view current version number using the following command:
$ xcrun agvtool what-marketing-version
- Build Number
We can view current build number using the following command:
$ xcrun agvtool what-version
Update to Next Values
- Next Version Number
It's not ideal to automatically upgrading to next version so we have to specify the value of the next version that we will be updating to in the command. We can update the value to next version number using the following command:
$ xcrun agvtool new-marketing-version 2.0
- Next Build Number
We can increment the build number to the next build number using the following command:
$ xcrun agvtool next-version -all
We can also specify the specific value of the build number using the command, e.g. if we want to set the build number to 3.2, then we can do that with the following command:
$ xcrun agvtool new-version -all 3.2
Note that when we update the version or build number values, it changes the in the
Info.plist file or
.xcodeproj file. We need to have some source control mechanism to commit the changes back into the source control.
As of now, we have seen that we can use Apple's native command line tool to manage the version and build numbers, however, there are some other third-party tools like Fastlane which can also do the same thing. Fastlane has actions to increment both the build and version number. The increment_version_number action can be used to increment version number, which has various options as well. We can bump to a major or minor version, and we can specify the version number.
increment_version_number( bump_type: "major" )
The increment_build_number action can be used to update the build number values.
increment_build_number( build_number: "5" )
There are a number of options to manage the build and version numbers but these actions also use agvtool to all these changes.
Apple's native command line tools, like agvtool, can give you control over the version and build numbers of iOS apps. It takes a little bit of scripting to manage everything from the source code, i.e Infrastructure as Code, for iOS apps rather than relying on third-party frameworks. I hope you enjoyed this post; feel free to share your experiences with using agvtool.