Automating Flutter App Versioning Using Fastlane Plugin

If you’ve ever developed mobile applications and published them to their stores, then you are aware of the specific rules of versioning an app. Those rules revolve around two properties: App versioning and incrementing build number.

Getting our Facts Right

App Versioning

Versioning is a critical component of an app upgrade and maintenance strategy.

On iOS, the app version is presented by the CFBundleShortVersionString key that must correspond to semantic versioning. This key is a machine-readable string composed of one to three period-separated integers, such as 10.14.1. The string can only contain numeric characters (0-9) and periods.
Each integer provides information about the build version in the format [Major].[Minor].[Patch]:

Source

On Android, the app version is presented by the versionName inside of the build.gradle file. Android doesn’t enforce any rules when it comes to specifying the name.

Build number

Build number (CFBundleVersion on iOS, versionCode on Android) is an identificator that is used only to determine whether one version of an app is more recent than the other, with the higher number indicating a more recent version. Both Google Play Store and Apple AppStore use the build number to protect against downgrades by preventing users from installing an app with a lower build number than the version currently installed on their device. On Android, that number is an integer, but on iOS, that number can be presented both as an integer or as a semantic version.

Flutter's Way of Handling Stuff

The Flutter team has decided to handle this very neatly; they have a property in pubspec.yaml called version that follows this pattern: {major}.{minor}.{patch}+{version}. Therefore, in order to publish our app with the app version of 1.2.4 and build number of 5, our pubspec.yaml would have a version property that looks like this: version: 1.2.4+5. The next time the application goes through the build process, those values are applied. However, the question is, how we can automate this whole process of versioning?

flutter_version_manager plugin for Fastlane - The Fun Part!

Fastlane is the easiest way to build and release mobile apps. It has been used widely by the mobile application developers community. It’s written in Ruby, is open source and it has great support for developing your own custom plugins. 

This plugin heavily resides on having a git repository and at least one commit as build number is applied through timestamp of HEAD commit. By leveraging the power of git, we no longer have to worry about incrementing versionCode/CFBundleVersion. As for the app version, version.yml file that we had to create manually should be used as a single source of truth. Now, there are a couple of ways of handling an app version using this plugin:

That being said, a DevOps engineer has power over versioning. For example, he may create a patch pipe that runs on patch branch that will call deploy_as_patch lane which automatically bumps patch version and deploys the latest version. You can find an example of Fastfile here. Full documentation is available in a git repository.

This plugin is open-source and any contributions to it are more than welcome. Happy DevOpsing! ^^