Firebase Android App Distribution
First impressions
I’ve been around Android development for so long now that my early app distributions were to root the device that wanted it installed and manually plug in the cable to install it via command line. Not the best experience nor the reach you wanted. How do you explain to someone who joined a beta program, that they have to root their device? Thus throw away all their guarantees from the manufacturer and maybe even brick their phones.
Then came other app stores where you could distribute the apps. Later you could even do dropbox links given that your user had checked “Trust unsafe sources” in their settings. To this day, I still remember that on dropbox-sharing links, you have to alter the query to start a download directly from a zero to a one. Otherwise, it didn’t work from most devices, and you ended up on a webpage where you weren’t allowed to download.
Finally, in 2014 came Beta by Crashlytics (later Fabric Beta), which made it simple to distribute our apps and manage our testers. And that it worked on both Android and iOS was probably the actual selling point. But all good things must come to an end, and due to Crashlytics (and Fabric) being acquired by Google, they saw it more fit to move the functionality under the Firebase brand instead, and so arose Firebase App Distribution.
Firebase App Distribution is still in Beta, but I think it’s stable enough. The fact that the team behind it contains members from the team that worked on Fabric Beta assures me so. The thing that gives me a clue that it’s still in the making is the minimal set of features and some hidden limits.
To give you a taste of the ease of use, let’s dive in. After reading this, you should feel comfortable in distributing your app via Firebase, and what limitations there are to consider. You have to have your app connected to the Firebase platform first. And if you’re still on Crashlytics, it’s time to migrate since it will close down comes end of March.
Get Started
Click App Distribution in the main menu. You’ll see a welcome screen and a video on how to get started. Click the “Get Started” button, and you will get to the main panel, which will consist of three tabs; Release, Invite links & Testers and Groups.
Testers and Groups
Let’s start with “Testers and Groups.” Here you can create a tester by typing an email address; the user will then get an email asking if they want to join.
Let’s create a group, as well. Just click on the “Add group” button. But beware that you can’t change the name of the groups, nor the ID. So use caution since this is how to refer to them from an API like Fastlane and similar.
Now we can add our user to a group as well as remove them. We can also delete both groups and users with ease. So don’t be afraid to test, test, and test. But once you are done testing, I’d say it’s good to try to set your structure and stick to it. Otherwise, you might end up with a bunch of poorly named groups. Or worse, manually handling the move of testers from one group you wish to delete to a new one.
Invite links
Invite links are an easy way of acquiring your testers, you create a link to share, and the user can input their mail address to sign up. There is also an option to choose if sign-ups from a specific link should end up in a particular group. Unfortunately, you can only specify one group.
There’s also a neat feature to specify which domain the email must belong to be able to sign up. With the same limitation, only one. Which makes it tedious for me since we have 10–15 domains in our organization, and I don’t want to create 15 invite links.
Once again, once an invite link is created, it can’t be altered. I don’t mind this as much as invite links come and go, and you probably will want to rotate them, so that old ones don’t get spread. But still, it would be nice to be able to update, for example, to what group the link should feed with users.
It can become a real problem if you have many test users signing up and add them to a group since each group has a hidden limitation to 200 users per group. And would you hit that limit, the next undocumented limit would probably also be a problem, it’s that your entire project only can have 500 users. These limits are not set in stone, but you can’t change them yourself. But if you have over 500 testers, you might be okay with the luxury problem, and you can always reach out to Firebase to see what they can do.
The last thing on invite links is that you need to specify which application the link should invite to test, among the ones registered in your project. It’s hidden at the top. I’ve missed it a couple of times already…
During the writing of this post, Firebase has updated the UI for invite links to include the information for which app the invite links are created for, so they listen to feedback for sure. It seems as they are swift to update too.
Releases
Releasing an app is also as simple as drag and drop your apk-file into the web console, if you’re into the drag and drop business. But don’t worry, there’s also support for Fastlane, Gradle, and Firebase CLI if you, like me, prefer the more automatic way of uploading. I’ve only tried Fastlane myself, and it was easy to set up, and the documentation was very straight forward too. So now, each time we merge a pull request into our alpha branch, our build server pushes it to Firebase.
When using the web console, one must once again pay attention to which app that is selected in the semi-hidden drop box at the top since it will only affect that application. But here’s the twist, you can drag any apk into any app. This means if you have to flavors or one beta and one alpha version, you can mix and match the APKs as you wish. The area to drop the apk literally says, “Drag any .apk here to create a new release.”
This is both good and bad. The good part is that some rule-set does not force you; you can just test. But the bad thing is that you might expose your testers to inconsistency since they get the application name and version from your APK. So they might sign up for “Awesome App Beta” and then a few weeks in only see the application “Awesome App Feature-Kangaroo.” It’s probably not the end of the world, but testers are easily lost, so let’s not give them reasons for it.
Conclusion
All in all, Firebase App Distribution is nice and simple, maybe even too simple. But it’s nice to have a testing environment where you can just get started without caring to get the routine going. And when you’re all set and done. Do some polishing before you invite your real testers and give them a great experience.
