Working with startups means developing new products and services and trying to bring them to the market as fast as possible. This entails that our development process must be fast and precise as we iterate through it - we must ensure that our iterations are available as soon as possible and that they fall in the right hands - our testers and users.
When it comes to development in general, we must expose our builds as soon as possible in our agile environment. Precisely, on Android, when a development build is ready to distribute, there are a few options to distribute it to your users:
Distribute a build via email or send it in a Slack message
Upload a build on cloud storage such as AWS
Upload a build to Google Play Store (tracks/channels)
Use some other tools such as Fabric, Firebase App Distribution, Microsoft App Center, etc.
This article will cover distributing builds with Google Play Store (Internal App Sharing) and Firebase App Distribution. The first and the most important reason for using those is to ensure that testers and users can download our build with ease. Secondly, we wanted to automate things as much as possible, and thirdly, they are compatible with the tools we already use.
To connect all the pieces, we had to have rock-solid CI (Continuous integration), and the decision fell on Gitlab. Gitlab offers an all-in-one solution that we can easily integrate into our processes. In this case, it means that we can use it with tools such as Fastlane.
For those who do not know, Fastlane is an app automation tool for delivering iOS and Android builds. With Fastlane, you can distribute, build, and publish builds. Also, you can take screenshots, connect with other tools (such as Bitrise, Gitlab, Travis, etc.), and best of all - it is free and open source. When you pair Fastlane with the CI of your choice, you get a game-changing way to distribute mobile builds. Although we will not cover integration with Gitlab CI in this article, here you can find more information about Fastlane and how to configure it. If you want to use Fastlane on your local machine, you can install it using RubyGems or Brew on macOS - just check the official guide for more information.
Before Firebase App Distribution came out, we were using testing tracks on the Google Play Store to distribute our Android builds. Specifically, we used Internal App Sharing, which combines readily with Fastlane. You can do this by adding the following line to your Fastfile:
Also, you must specify Google API key and package name in Appfile:
Unlike in other tracks (Alpha, Beta, Production) where the build is available after some time, the Internal App Sharing builds are available right after uploading. After completing the upload, you will get a link to distribute it to your testers/users. If you want more options (like a Slack notification when a new build is available), you must do it manually through Fastlane actions in the lane. Here are some examples:
To shorten your link with Bitly:
client = Bitly::API::Client.new(token: ENV['bitly_token']) bitlink = client.shorten(long_url: uri)
To send Slack message:
slack( icon_url: “url_to_some_cool_android_logo", username: "Android", message: "DEVELOPMENT build is deployed on <" + bitlink.link"|GooglePlay - Internal App Sharing>", success: true, slack_url: your_slack_url, )
Fastlane has many actions available, and if you do not find what you are looking for, you can also take a look at plugins. Another benefit is that the uploaded build doesn't need to be signed, and multiple builds with some code version can be uploaded. That means there is no unique version of code enforcement, which speeds up the deployment process because there is no need to bump code version after making some changes. The main downside is that before uploading the build to Internal App Sharing, the app needs to be created on Google Play Store. In most cases, this can be a tedious job, especially when creating a new project from scratch. Also, testers must enable the Internal App Sharing option in the Google Play Store app, which is hard to find in the settings. For a better understanding of the Internal App Sharing, it is useful to consider both advantages and disadvantages.
Builds are available right after uploading (via a link, as mentioned above)
Build does not need to be signed
Multiple APK with the same code version can be uploaded (no unique version code enforcement)
Supports up to 100 testers
You must create an app on Google Play Store
Users must enable Internal App Sharing option in Google Play Store app
Users must join the Test program and must be added through Google Play Console
Release notes and app version is hard to follow
Testers can not download builds without Google account
Firebase App Distribution is a new tool from Firebase that aims to replace Fabric (if you are an iOS developer, you will find App Distribution very similar to TestFlight). You can integrate it with Fastlane but also with Gradle, or use Firebase CLI. We decided to give Firebase App Distribution a try because it solves almost all the cons for Internal App Sharing mentioned above. It is simpler for us to configure (and add new testers), and it is more straightforward for testers to try out the latest build. It is convenient for testers because they have an App Tester app for tracking release notes and downloading new builds in one click. For developers, the valuable part of Firebase App Distribution is a dashboard for tracking who has accepted and installed a build, and for changing release notes and adding new testers. Another benefit is that Firebase App Distribution supports iOS, which means it is easy to unify both platforms.
One significant drawback is a lack of support for Android App Bundle. Still, we hope that this will be added soon because AAB is required for the new apps starting 2021, and because Firebase App Distribution is currently in Beta (at the time of writing this article).
// Run this command in the root of your project) fastlane add_plugin firebase_app_distribution
Add Fastlane action in Fastfile:
firebase_app_distribution( app: "your_app_id", testers: "email@example.com, firstname.lastname@example.org", release_notes: "Lots of amazing new features to test out!", firebase_cli_token: "your_token", apk_path: "path_to_your_apk" )
And that is it. After completing the action, your testers will get an email that a new build is available with all the instructions to download and install your build.
Easy for testers to use
Builds are available right after uploading (via link or tester app)
Build does not need to be signed
Multiple APK with the same code version can be uploaded (no unique version code enforcement), but if your APKs are identical, the newer one will be ignored
Testers have an app for downloading and tracking new builds
Invitations for testers are dead simple and testers groups are supported
New testers can be added in Fastlane configuration (Fastfile)
Dashboard to view insights
Release notes can be attached in the Fastline action or can be added through Dashboard
Support for iOS
Supports up to 200 testers
Testers cannot download builds without Google account
Does not support AAB (Android App Bundle)
Currently in Beta
We find it very important to send development builds as early as possible to our testers and beta builds to users. In that way, we ensure that what we are building is good and that we are moving in the right direction. We consider a good CI/CD as a vital part of our development process's success, so if you are not using one, we suggest you try it. The exact tools that you use are not that important, pick what best suits you and your needs. We decided to go with Gitlab (for the CI) paired with Fastlane and Firebase App Distribution, and so far, we are happy how things are working.