Auto-Incrementing Build Numbers in Xcode

There are a lot of non-code related hardships we come across while developing a software. One of them is the test. On which server will the Beta distribution be? How will be the CI-CD processes? Where will the code be stored? How will the technical information be distributed in the team? What is versioning? What is Build Number? Is it just the number that Apple Store  wants us to increment and that goes to 2.0 from 1.0 as the app is published? And many more questions come up in our minds.

One of the problems we come across while developing a software is versioning. We come across it frequently in our daily lives. Numbers like v1.4.3 or x.y.x must have caught our eyes in the menu of the software products, profile page, settings page, on the left or right… But, how and relative to what is done this so called versioning? What it is done relative to and how it is done depends on the position of the company in the industry, what it does and whatever the developer wants. There is not a fixed versioning technique in the world, that being said, the techniques used are very similar to each other. And the most commonly used one is semantic versioning. And we, as Peakup Labs mobile developers, use this type of versioning. You can learn the details of semantic versioning here.

What is a Build Number?

I will just go over the basic details. While developing a software product we usually don’t put forward the whole product at a time. We start, get something done and then send it to the user/tester/manager. The receiver checks it and gives feedback like “can we add this, can we change this, there is an error here” etc. We do it and resend it.

But how the person who we send it to will distinguish these 2 products? Well, here comes the build number into the play. If the second product’s number is 1.1, while the first product’s number is 1.0, it can easily be recognized that the second product came out later. For example , when someone is using the first product instead of the second product and talk about a bug we fixed in 1.1, we can tell them to download the 1.1 version and that we have fixed that bug there.

Both build numbers and version numbers are numbers used to identify a product.

These numbers for sure don’t just help to distinguish versions. Also, the builds that have the same version number are not published since AppleStore and Google Play Store don’t see them as an update. Build number and version number should be incremented in a certain way. Version number can be incremented manually. Because the system can’t know or determine the size of our update, who knows it is the developer himself/herself so it is more convenient for the developer to increment it manually. But you don’t need to increment the Build number manually all the time. As befits the name, it is a Build number. It is incremented in every Build. I think manually incrementing it is against the spirit of being a developer. It is contradictory to manually increment the build number all the time while trying to automatize the system and the app we are developing. 🙂

IOS Versioning System

And now let’s get down to the business. In this article I will talk about how we can automatize the build number or set it to git commit. iOS applications have 2 different types of version numbers like we mentioned above.

  • Short bundle version string CFBundleShortVersionString (e.g. 1.12)
  • Build Number CFBundleVersion (e.g. 190)

Each “Short version” contains more than one build. And each build corresponds to “Bundle Version.” Which means that while the build number is incremented in every build, the version number is incremented after a few builds. As you can see on the screenshot below, the version with the 1.4 version number contains two different builds of numbers of 34 and 35.

Now that we have talked about version and build number way too much, let’s talk about how to auto-increment the Build number without further ado. We can achieve this by using a very simple Shell script.

buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${PROJECT_DIR}/${INFOPLIST_FILE}")buildNumber=$(($buildNumber + 1))/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"

The script above takes the build number in the plist file, increments it 1 and rewrites it to the plist file by using the PlistBuddy feature of XCode.

  • ${PROJECT_DIR} :  Full path of the main project
  • ${INFOPLIST_FILE}:  Full path of the info.plist file

Auto-Incrementing the Build Number in XCode

It’s all well but how do we do this in XCode? First of all, this article is written with the XCode 11.4 version. If in new versions of XCode something changes, the article will be updated. If it not updated, it is enough for you to reach out to us and it will be updated immediately. As long as you follow our instructions step by step, you can auto-increment the Build number.

    1. Choose the Application Target field, and then the Build Phases tab.
    2. Click the + button above to add a new Script.
    3. Choose New Run Script Phase in the new tab
    4. When the new Script screen is open, write the script piece we see in the screenshot below. By the way, you can change the name of the script. Naming… Boy, do I love it!
    5. When you build the project your Build number will automatically increment.

As well as this method of incrementing the Build number is, I just can’t get myself to like it. 🙄

I hear you guys saying “For God’s sake dude, did you just write this for nothing, and did I read this for nothing so far, how would you like us to increment the build number your majesty?” This method is not the best practice when it comes to incrementing the Build number. So, what is the best practice concerning this?

It is, of course, to connect the Build number to the Git commit number.

How Can I Connect the Build Number to the Git Commit Number

If you connect the build number to the git commit number, the build not will go high to the sky. And it is guaranteed to always be more than the previous version just like Apple Store and our colleagues want. Incrementing this number in every build can cause this number to be too high in time. Well, does it harm anything when it is too high? Nope. I connect it to the git commit number just because I want to 🙂

https://gist.github.com/alparslandev/51ad5bc0192ad4d52ffcac02d5e3b541

I wrote the necessary script in the gist I shared above. As you can see it is possible to increment the Build number depending on the commit number. You can write the script in gist to the space I showed on the 4th step like I said above.

Click here for our other articles about iOS Developemnt
Click here for our articles on Android and Kotlin.

Alex is a good software developer. He likes to improve himself and learn new things. He is not one of those who learn the build number when the app is to be published on Apple Store. He had already learned the value of versioning and build number a long time ago. Alex is not one of those who say “oh dear the build number stayed as 1.0, let me make it 2.0” when he can’t send an update to Apple Store. Alex automatizes the build number and pays good attention to the versioning number.

Version notes are very important for Alex. He always writes comprehensible and well-liked version notes. Even if he is writing a very small application, he builds the versioning system well and increments it. A good beginning makes a good ending in the end, right? Alex knows that if he says “Ah, never mind!” even once, it bodes no good.

Be like Alex. Work hard.

Resources

https://developer.apple.com/library/archive/technotes/tn2420/_index.htmlhttps://crunchybagel.com/auto-incrementing-build-numbers-in-xcode/https://www.mokacoding.com/blog/automatic-xcode-versioning-with-git/https://fuller.li/posts/versioning-with-xcode-and-git/