Looking for a free app distribution tool? Try Fastlane

Make distribution pipelines your way

After successfully developing your mobile application, the next step is to distribute your apps to stores. Of course, you must test your work before releasing it. In terms of releasing, Fastlane comes into the picture which will make developers' lives easier by making it very simple to release apps to stores with one command.

Fastlane is an open-source tool that you can automate beta deployments and release of your iOS and Android apps. In Fastlane’s world pipelines are called “lanes”. Fastlane comes up with a bunch of pre-defined lanes and we can create custom lanes as well. With Fastlane it is not just about uploading the app to the store, you can automate the system to update the store presence and many more with just one command.

In this article, I’m going to show you the big picture of using Fastlane. This will help you to get a high-level idea of how Fastlane works.

I’ll utilize the diagram below to provide you with a better understanding of Fastlane’s functionality.

Very simple lanes for Android and iOS

Android

Let’s use the below prod_release lane with the above diagram to discuss what's happening here.

lane :prod_release do
  increment_version_code(version_code: Time.now.to_i)
  gradle(
    task: 'bundle',
    build_type: 'Release'
  )
  upload_to_play_store(rollout: 1)

The code written above is a Ruby code. You must write your lanes in Ruby.

1. As the first step, we have to start the lane. We can run the below CLI command for that.

fastlane prod_release

2. Now we update the version code. In the code above I’m setting the current time in milliseconds as the version code. You must make sure the version code you put here is greater than the one in the current production app. Here the increment_version_code is a plugin we can download from here.

3. Then the app starts to build. Which executes by the gradle lane. gradle is a pre-defined lane in Fastlane. As parameters, I’m passing ‘bundle’ and ‘Release’. This means we are going to build .aab file with a release build. Other than ‘bundle’ we have ‘assemble’ for building the .apk file. Other than ‘Release’ we have ‘Debug’.

4. After finishing building upload_to_play_store pre-defined lane will run. That means we upload the .aab file. Passing 1 as the rollout means we are going to roll out the app to 100% of the end users.

It is not a good practice to release to end users right away before doing atleast sanity test in production.

Instead of uploading the .aab file directly to the production track you can upload it to the testing track as well. What you have to do is just add the below parameter. You can find more info about this lane here.

  upload_to_play_store(
    track: 'alpha'
  )

5. Other than uploading the .aab file you can upload metadata.

What is the metadata?

For Android, the metadata will be the app title, short description, long description, screenshots, and many more. you can find all the metadata available here. You need to maintain a metadata folder inside Fastlane directly as shown below. You can find more about metadata here.

sample metadata folder of Android

Fastlane can connect to Google Play Console via an API file. You can read this to create an API file. Then with the help of the API file, you can automate uploading the app and metadata easily. You should securely store this API key somewhere safe since it can be used to manipulate your Google Play Console account.

iOS

Let’s use the below prod_release lane with the iOS part in the above diagram to discuss what’s happening here.

lane :prod_release do
  match
  update_code_signing_settings(
    profile_name: <profile_name>,
    team_id: <team_id>,
    bundle_identifier: <bundle_identifier>,
    code_sign_identity: "iPhone Distribution",
    build_configurations: "Release"
  )
  increment_build_number
  build
  deliver(
    submit_for_review: true,
    automatic_release: true,
    phased_release: true,
    force: true
  )

private_lane: increment_build_number do
  app_store_latest_bn = app_store_build_number()
  testflight_latest_bn = latest_testflight_build_number()
  
  ...logic to increment build number
end

1. As the first step, we can run the build command to start the lane.

fastlane prod_release

2. Then we have to do code signing. This means we have to create the Provisioning profile and certificate to sign the application. The Fastlane will do that to us. So we don’t have to do anything. match and update_code_signing_settings do the code signing. You can find more information about this from here.

3. Then we update the build number. In the above code, I have written a custom private lane increment_build_number to update the build number. Since this lane is private no one outside the file can access this lane. Here the logic is I get the latest build number from the current production build, increment by one, and update the new app with the new build number.

4. Then we build the ipa file.

5. Then we do the ipa file upload to App Store Connect. Again I’m saying, that directly releasing to production is not a good practice. Therefore, you can do a TestFlight release as well. Check here to learn more about uploading to TestFlight.

6. You can upload metadata as well. As shown below you should have the folder and file structures ready before uploading the metadata.

Just like in Android, Fastlane has a connection to App Store Connect to automate app distribution. So here also we have to create an API key file and add it to the Fastlane folder. You can find more info here.

Conclusion

In this article, I showed you a high-level view of how to use Fastlane in your project to automate app distribution. You just have to run one command and the rest will be handled by the Fastlane. Fastlane documentation provides all the information needed to integrate Fastlane into your project. But based on your project's complexity, the complexity of the script you have to write will differ. Hope you learned something new from this article. I’ll see you in a new article soon. Cheers!