React Native lovers… Flutter novices… iOS and Android engineers, and Cordova advocates (if you still exit)… Versioning your product can be a complicated task.
iOS and Android have different terminology around build number and build version. In this article you will learn the correct way to bump up your application version and a guideline for approaching versioning. Let me introduce: Conventional Versioning.
Let’s first clarify some of the terminology around versioning your build on iOS and Android. For iOS there are two values: Build and Version. For Android there is two: versionCode and versionName. For the sake of the sanity of those who develop cross platforms, let’s unify this terminology to:
Build (iOS) versionCode (Android) (this needs to be unique per release)Version (iOS) versionName (Android)The fact of the matter is, that these values can be configured however you see fit for your project, there is no correct way, but only popular methods and guidelines.
Let us first tackle Build Number. This is an internal number. From a popular stack overflow thread on the topic, the top answer suggests the following: “Many developers start the Build number at 0, and every time they build they increase the number by one, increasing forever.”.
Build / Version Code on iOS / Android
In layman's terms, every-time we hit the build button on iOS or Android, we increase the Build Number. e.g. Release 2.1.0 may be build 542, as it took 542 builds to get to a 2.1.0 release.
Next is Build Version, this is a customer facing version. For consumer applications semantic versioning is out of scope, because “the version is not only a version, but also a marketing asset.”, examples on this Stack Exchange thread. The main thing to consider is to pick a versioning system which makes sense for your product. e.g.
Version / Version Name on iOS / Android
Following these guidelines will prevent the problem of missing versions. As the Build Version should only be updated on a successful release. e.g. you release to Test Flight but the build fails with incorrect metadata, you do not need to bump Build Version again for the next release, because Build Number will increase by +1 with each build, and that is the value which needs to be unique per release.
e.g. Build Version: 1.1.2, Build Number: 544 ? (metadata issues on App Store, next build) -> Build Version: 1.1.2, Build Number: 545.
We are a leading niche digital & tech recruitment specialist for the North East of England. We Specialise in the acquisition of high-performing technology talent across a variety of IT sectors including Digital & Technology Software Development.
Our ultimate goal is to make a positive impact on every client and candidate we serve - from the initial call and introduction, right up to the final delivery, we want our clients and candidates to feel they have had a beneficial and productive experience.
If you’re looking to start your journey in sourcing talent or find your dream job, you’ll need a passionate, motivated team of experts to guide you. Check out our Jobs page for open vacancies. If interested, contact us or call 0191 620 0123 for a quick chat with our team.
Follow us on our blog, Facebook, LinkedIn, Twitter or Instagram to follow industry news, events, success stories and new blogs releases.
Back to Blog
Northumbria House, Samson Close, Killingworth, Newcastle, NE12 6DX
