Mobile software development poses a number of unique challenges. The ecosystem is quite diverse: there are over six billion active smartphone devices worldwide, with a wide variety of screen sizes, processors, hardware, OS versions, languages, and features to consider. On top of that, the release process is gated and is not entirely controlled by you. You have to follow the policies and requirements set forth by Apple and Google, and these are generally getting stricter by the year.
Still, mobile development has come a long way in the past decade, and there are now a number of best practices and tools that you can lean on to make things run more smoothly. fastlane is one of those tools.
fastlane offers developers a comprehensive set of actions that help speed up and automate the mobile release process. Using fastlane, you can build and sign your binaries, run tests, deploy updates to beta users, generate marketing screenshots, submit builds to the Apple App Store and Google Play Store, and much more.
In this guide, we’ll provide an overview of how fastlane can level-up your team’s mobile release process, and we’ll compare fastlane functionality with the traditional, manual alternatives. Even if you don’t want to or aren’t able to implement your entire release pipeline in fastlane, this guide will offer some key building blocks you might want to draw from.
Part of the challenge of releasing mobile apps is that there are a lot of steps involved, and many of the steps (like generating marketing screenshots and incrementing version numbers) are performed manually. This makes them error-prone and time-consuming.
Some companies attempt to address this challenge by throwing people at the problem, hiring dedicated mobile release managers or technical product managers (TPMs) to run releases. This can be expensive, and even with a great person managing your release process, engineers and others on the team still have roles to play and tasks to handle throughout each cycle. Also, as responsibility for releases moves away from the team building the product, new bottlenecks and single points of failure can arise. For example, what happens when the release manager is out of the office?
“Brian is the only person who knows how to do a release, and he’s on vacation, so we’ll have to wait.”
Joshua Liebowitz, Firebase Dev Summit 2017
Building a clear process, putting individuals in charge of various parts of the release, and creating robust communication channels can help safeguard against some of these stumbling blocks and improve your overall release process. But these solutions also create their own challenges.
By distributing the work, more people and coordination are required at each key juncture. Handoffs become critical, and any missing link in the chain causes a delay. This leads to specific challenges like the following:
This all becomes very difficult to track, and a lot of time is wasted between tasks. Automation becomes an important requirement for streamlining each of these processes, and fastlane can help with several of these steps.
fastlane is an open-source tool aimed at simplifying Android and iOS deployment by automating large portions of your mobile release workflows. It’s an extensible framework that comes with many prebuilt actions for common tasks, and it gives you the ability to create your own actions if needed as well.
You can use these actions collectively in lanes. For example, a complete lane for an Android app might build the application, run unit tests, take updated screenshots, generate the application bundle, and upload it to the Play Store.
In the remainder of this guide, we’ll share some specific tips for integrating fastlane actions into your existing release process, outline some key actions almost every mobile release team will want to leverage, and point you to other resources where you can learn more about fastlane along the way.
If you’re already using CI/CD tools to automate portions of your release, you’re in luck. fastlane has integrations with many of the major CI providers, and it’s a command-line tool that can run on any environment that runs Ruby. This means that once fastlane is initialized in your project, all your developers and CI environments should be able to run any of the lanes you set up.
Let’s look at some of the key pieces of a new fastlane project. Typically, a new fastlane project has two configuration files:
The <code>Fastfile<code> is where lanes and actions are defined. By committing this file to your project’s source code, you can ensure that every developer runs the same steps when building and releasing your app.
A lane defines all the actions that should run when the lane is executed. Typically, you might have a <code>build<code> lane that builds your application’s binaries, a <code>test<code> lane that runs your tests, and a <code>deploy<code> lane that pushes updates out to the app stores.
Of course, this is just the tip of the iceberg. Your lanes can call other lanes and can handle many other tasks like taking screenshots, signing your binaries, submitting builds to TestFlight or adding builds to testing tracks in Play Console, and automatically generating changelogs. You can find lots of examples of real Fastfiles in this GitHub repository.
For iOS apps, fastlane lets you authenticate with either an App Store Connect API key or via an App Store Connect user account. Note that there’s more friction and potential for flakiness with the latter, now that Apple requires two-factor authentication on all App Store Connect accounts. This is especially true when using fastlane within CI or via bots. Unfortunately, using the App Store Connect API key approach limits you to fastlane actions that call official App Store Connect API endpoints, and these represent just a subset of all the functionality fastlane offers.
On the Android side, you can use a service account and API keys generated via the Google Play Console to authenticate.
One of the biggest challenges when automating app releases on the iOS side is code signing. fastlane offers match, an action that allows your team to share a signing identity and certificates. By putting the certificates and profiles in a shared git repository or S3 bucket, you can set permissions such that any approved engineer can sign builds and push updates. match even renews expired credentials automatically.
With some of the basics covered, let’s look at how you can use fastlane to build, test, and submit your apps. For these examples, we’ll use an Android app that’s being pushed to the Google Play Store, but fastlane offers analogous functionality for iOS apps.
You can also add a lane to build a release APK for your project:
If you want to use the Android App Bundle instead of an APK, replace <code>assembleRelease<code> with <code>bundleRelease<code>. Google Play won’t accept your AAB unless it’s signed. To automatically sign the release as part of your lane, you’ll need to add your signing configuration to your app’s <code>build.gradle<code> file:
With your <code>build<code> and <code>test<code> lanes ready, you can run either lane manually by calling the following in your terminal:
There is much more you can do during the build and test steps. For example, fastlane includes actions for SonarQube and OCLint static code analyzers, code coverage generation, and Swift Package Manager.
Another time-consuming pre-release task involves capturing screenshots of your app and uploading them to each app store. Although many teams don’t update screenshots regularly, whenever they do it’s no easy feat to generate and upload screenshots across all the necessary screen sizes and languages they support.
Fortunately, fastlane can automatically take screenshots of your app and upload the screenshots to the Play Store or the App Store.
For Android apps, fastlane uses the screengrab action. After you install the Ruby gem and set read and write permissions, you can add a UI test that runs your app and takes screenshots of specific views you want to highlight:
After you’ve added calls to take screenshots throughout your app, you can add a new lane to your <code>Fastfile<code>:
When you run this lane, fastlane will run your UI tests, sending the finished screenshots to the <code>fastlane/meta<code> directory. In the next section, you’ll see how to upload these screenshots to the Play Store along with other app metadata.
Now that you’ve seen how to build your app binaries, run automated tests, and take screenshots, let’s look at how to actually submit your app to the Google Play Store. fastlane’s supply action can upload your binaries, metadata, app icon, and screenshots so that when an update is pushed, everything is automatically taken care of.
As with some of the other actions above, you just need to create a new lane or update an existing one for deploying your updates.
You can see that, as part of this <code>deploy<code> lane, we have also called the other lanes previously defined in this guide. This final lane will run the unit tests, build the APKs, take screenshots, create an OBB bundle, and upload it to your <code>internal<code> track in Google Play Console. This will allow your team to download and test the update before you commit to a <code>beta<code> or <code>production<code> release track.
The tools available to mobile developers to automate releases have come a long way. If you’re still struggling with manual, error-prone releases that require specific team members to be present and run operations manually, it’s time to revisit your process.
Of course, changing an existing release process is also risky. If you’re new to tools like fastlane, you may want to start by implementing just a couple of the more straightforward actions (like automated tests or screenshot generation). As you build confidence in the tool and your team embraces automation, you can move on to internal and beta releases, and work your way even closer to an entirely automated mobile release process.