Why Incrementing Your Build Number is Crucial for Every App Release

If you’re looking for the springboard to help you take your device fleet to the next level by getting ahead of the curve, this webinar is for you.

In application development, a build number is a unique identifier that distinguishes each specific build of the same application. It plays a crucial role within the versioning system, particularly in activities such as testing, deployment, and debugging.

Think of build numbers like versions of your favorite recipe. Imagine you have a chocolate chip cookie recipe that you frequently update and improve. Each time you make a change, like adding more chocolate chips or trying a different type of flour, you give the new recipe a unique version — v1, 1.1, 1.2, etc.

What Do Build Numbers Do?

A build number is an incremental identifier that uniquely identifies a specific build of the software, often used alongside other versioning identifiers like version codes and names. The thing is, there isn’t a one-and-done definition for how developers use build numbers across various platforms. For example, in the attached screenshot, the version code of the YouTube application is 18.04.32, and the build number is 1535755712.

The build number aids developers and users in tracking and distinguishing between different iterations of the application, which is especially vital in CI/CD pipelines where multiple builds may be generated rapidly.

Build numbers are either manually set or automatically generated through CI/CD pipelines during software creation. The number is then stored as an environment variable, hardcoded in the build configuration file, or derived from the CI/CD system.

For those doing manual builds in Android Studio, you can manage build numbers and create release tags directly within the IDE and through the command line.

Setting and Viewing Build Numbers in Android Studio

1. Setting the Build Number:

a. Modify build.gradle:

You can set and manage build numbers in your build.gradle file. Here’s how you can configure it:

android {
…
defaultConfig {
…
versionCode 1 // Increment this for every build
versionName "1.0" // Update as needed
def buildNumber = System.getenv("BUILD_NUMBER") ?: "1"
buildConfigField "String", "BUILD_NUMBER", "\"${buildNumber}\""
}
}

Ensure that you increment the versionCode for each build to reflect changes.

b. Environment Variable:

You can set environment variables in Android Studio’s run/debug configurations if you need to pass the build number dynamically.

2. Viewing the Build Number:

In the Application: Display the build number in the app’s UI to verify the version. For example:

TextView buildNumberTextView = findViewById(R.id.build_number_text_view);
buildNumberTextView.setText("Build Number: " + BuildConfig.BUILD_NUMBER);

In Build Logs:

When you run a build, you can see logs in Android Studio’s Build window, where you can verify the build details.

Incrementing the build number:

With each new build, the build number increases. This can be automated by CI/CD tools or managed manually by developers.
Incrementing ensures that each build remains unique, facilitating clear differentiation between builds.

Incorporation into the build:

The build number is embedded into the application during the build process.
Incorporating the build number into the build process involves embedding the build number into the application at the time of its creation. This ensures that the build number is part of the application’s metadata, making it easily accessible for tracking and identification. Here's how it’s typically done:

Embedding in Metadata:

The build number is included in the application’s metadata, which can be accessed programmatically within the app. For example, in Android development, the build number can be added to the build.gradle file using the buildConfigField method.

Displaying in the UI:

Displaying the build number within the application’s user interface (UI) can help developers and users easily identify which build they are using. This is particularly useful for beta testers and debugging purposes.

Including in Logs:

Logging the build number during runtime can aid in debugging and monitoring. When issues are reported, logs can be checked to identify the specific build where the issue occurred.

Integration with CI/CD:

In a CI/CD pipeline, the build number is often set as an environment variable that is automatically incremented with each new build. This ensures that every build has a unique identifier.

By incorporating the build number into the build process, developers ensure that each build is uniquely identifiable, which aids in version tracking, debugging, and deployment.

The Importance of Release Tags in Build Releases

In addition to incrementing the build number with each release, it's also important to add release tags. Release tags play a crucial role in version control and deployment management. Here’s why release tags are essential and how they complement build numbers.

Release tags are labels assigned to specific commits in a version control system. They mark a point in the repository’s history as a significant milestone, often corresponding to a release version of the application. There are a number of reasons why you should use release tags, including:

Clarity and traceability: Release tags provide a clear, human-readable reference for specific releases. They help developers, testers, and users easily identify and reference particular versions of the software.
Version control: Tags are immutable pointers to specific commits, ensuring that the code associated with a release remains unchanged.
Easier Rollbacks: Tags make it simple to revert to a previous stable version if issues arise.
Deployment Management: Tags can be used in automated deployment processes to ensure only tagged releases are deployed to production.
Documentation and Release Notes: Tags can be accompanied by release notes, detailing changes and improvements in each version.

Recipe Versioning Analogy

To further illustrate, let’s return to the chocolate chip cookie recipe analogy:

Initial Recipe: Chocolate Chip Cookies v1.0 (Tag: v0.1)
First Update: Added more chocolate chips > Chocolate Chip Cookies v1.1 (Tag: v0.2)
Second Update: Changed flour type > Chocolate Chip Cookies v1.2 (Tag: v0.3)

Then, as the recipe progresses, you can have v2.0, with a tag of 1.1, noting that it’s the first iteration of version 2.

In this analogy:

The recipe name is like the application name.
The version number (v1.0, v1.1, v1.2) is like the build number.
The tags (v0.1, v0.2, v0.3) are labels you use to mark significant versions of your recipe.

Every time you tweak your recipe, you increase the version number and apply a new tag. This helps you track which version is being used and makes it easier to identify what changed or revert to an earlier version if necessary.

Similarly, in software development, build numbers are like version numbers for each build of the application. Release Tags are like labels you use to mark each significant version or release of the application. By incorporating both build numbers and release tags, you ensure a robust process for tracking, managing, and deploying software, making it easier to handle updates, debug issues, and maintain a clear history of changes.

Why Increase the Build Number with Every Release?

There are many reasons why you should increase the build number with every release:

Uniqueness: Ensures each build is uniquely identifiable, which is critical for tracking specific versions of the application in use.
Debugging: Simplifies bug identification by referencing the exact build where issues occur.
Deployment: Facilitates automated deployment processes by distinguishing between different application versions.
User feedback: Enables precise user and tester feedback by associating issues with specific build numbers.
Version control: Enhances version management by maintaining a clear history of builds and enabling easier rollback if needed.

Let me illustrate this with an example. Suppose the current version of an app is 7.1 with a build number of 1.1. When updating to the latest version, such as 7.2, the corresponding build number should increment to 1.2. It's crucial to maintain this incremental pattern, where an increase in the application version should correspond to an increase in the build number.

Common Pitfalls and Solutions

Whenever you deploy the latest version of your application with the same build number, the application does not install on your devices. Although the event feed in the Esper console shows a success message, the application was never actually installed on the device.

To solve this issue, we made Improvements in Esper Agent v7.10 and above:

Enhanced error messaging now alerts users when they try to install an app with the same names and build numbers.

Going forward, developers should increment build numbers to ensure successful installations and avoid confusion with existing versions on devices.

If you're still unsure about build numbers, our Support Team can help answer your questions.

FAQ

No items found.

Keep Exploring

Bharath C

Bharath is a Technical Support Engineer II at Esper, where he specializes in mobile device management. With a deep understanding of troubleshooting and providing solutions for complex technical issues, he plays a key role in ensuring the seamless operation of enterprise mobile devices. He's passionate about solving complex technical challenges and always eager to learn.

Learn about Esper mobile device management software for Android and iOS

Try Esper for Free

Why Incrementing Your Build Number is Crucial for Every App Release

What Do Build Numbers Do?