Automating app distribution using Bitrise
By: Alan Steiman
Tags: Bitrise, Fastlane, iOS, Automation, Xcode

This window contains all the workflows and configurations for the App, divided into the following tabs:

Workflows: where you can create, edit, remove workflows, a primary workflow is created by default with some basic steps Code Signing: where you can add the certificates and provisioning profile Secrets: to store ssh keys, passwords, etc Env Vars: to be shared across all steps in the workflow, for example the path to the .ipa file is an env variable Triggers: where you can run a particular workflow when there is a new pull request, code push in a branch, or new tag created on the repo Stack: to specify the stack to be used on the VM, version of mac OS, Xcode, Swift version, etc. A different stack per workflow can be configured. It is recommended to use the latest stack, however your app might not be compatible with it yet. Check the details of the default stack Bitrise.yml: auto-generated when you modify the other tabs, you don’t really need to modify this file

Workflows

A workflow is a list of steps in a given order to achieve anything. The default workflow created by Bitrise has the recipe to generate a .ipa file.

Steps can be re-arranged, add new ones, remove existing

Each step is open source, and the Github url is available with to contribute, report issues, etc. Each step has different variables/flags to configure. For example on the Archive & Export step you can define whether to use Bitcode or not.

This workflow essentially:

Ensures Bitrise uses the SSH key to access Github Clones the repo Pulls cache if exists with the aim to speed up the overall process, by avoiding the need of installing all the dependencies from scratch Executes pod install Archives the given scheme, and exports using the given config Collects the .ipa file, dsym folder, and other artifacts, and makes them available to download on every build detail page Pushes cache if required

Distributing to Firebase

Although Bitrise has its own distribution channel, I already set up Firebase to share the app with the client, the idea was to keep using the same.

There is a Firebase App Distribution step we can add to the workflow, in order to automatically upload the .ipa file to our Firebase account.

Steps related to Firebase

The step has to be placed after the Archive & Export step, to ensure the .ipa is available on the given path.

And the configuration of this new step is rather straightforward:

Firebase Distribution step

We need a Firebase Token that can be generated from the Firebase CLI. The SENSITIVE label is forcing us to create a Secret variable, this will ensure the token won’t be visible on the build logs App Path: by default the env var $BITRISE_IPA_PATH is filled out, nothing to change Firebase App ID: retrieved from the Firebase Admin Panel Release Notes File: it is committed together with the source code, so whenever it’s time to create a new build, I modify manually this .txt file Tester Groups: Firebase allows the creation of groups of testers, instead of specifying one by one

After this step, I added another one to upload the dsym to Firebase in order to visualize the crashes that may occur.

Chaining workflows

Remember the idea was to distribute two builds with different schemes.

First I renamed the primary workflow into something more comprehensive, for example firebase-stage.

Then created a new workflow using firebase-stage as base, and named it firebase-prod.

Finally, modified the Archive step to use the corresponding scheme and export method, and the Firebase step to ensure the .ipa is uploaded to the right App (I set up 2 different apps on Firebase).

One option to chain workflows is to use the built in buttons:

But these buttons will concatenate the steps of the given workflows, resulting in a long pipeline.

I forgot to mention that the Bitrise free tier has a limit of 30 minutes per build. Chaining the workflows this way will take more, trust me.

Luckily, there is another step you can incorporate that will trigger another given workflow.

So what I did, is to add this step at the beginning to firebase-stage, triggering firebase-prod. The free tier doesn’t allow simultaneous builds, so firebase-prod is put on hold and added to the queue. That is fine for me, there is no rush!

Now when I trigger a build manually (or schedule it to a specific day/time), both workflows will run in serial, and distribute 2 different .ipa files.

But what! there is more!