How to simplify the deployment of an iOS application using Bitrise

It’s no secret that developing, testing, and deploying requires a great deal of effort, time, and attention for teams, especially when manually making all these steps. You have to be careful with each step to avoid possible mistakes.

Here, automation of the whole development process seems to be a perfect way to increase your software product quality and save a lot of time for you and your team. Equally, it relates to the deployment process.

There are multiple means for configuring and proceeding with the complete continuous integration and distribution processes, with Jenkins and CircleCI being the most popular. This time, we’ll watch Bitrise in action.

Article content:

• Why Bitrise is the right option to choose
• Inside the process: deploying an iOS application with Bitrise
• Adding an iOS app to Bitrise
• Specifying the workflow
• Triggering builds in Bitrise
• How deployment works
• Deployment for a QA team
• Deployment for client and AppStore release

Why Bitrise is the right option to choose

No doubt, every automation tool performs in its own way. For me, there are several reasons why I pick Bitrise every time:

• It’s tailored to meet precisely app-related needs
• Workflow configuration is seamless
• Compilations are ready to deploy at TestFlight and the App Store

Yet, it’s highly possible that once you start to use Bitrise, you’ll find reasons to appreciate it.

Inside the process: deploying an iOS application with Bitrise

Developing for iOS is not always easy, so we’ll walk through adding an iOS app to Bitrise, managing code signing files, and deploying an app to Firebase distribution, TestFlight, and the App Store.

Adding an iOS app to Bitrise

Let’s look at the steps to bring your app to the tool.

1. Click the + sign on the top menu bar, select Add app, and follow the Create New App page.
2. Choose the account you want to add the app to.
3. Set the app’s privacy to either Private or Public and click Next.Select the Git provider service that hosts your repository, then find and
4. select your repository that hosts the project.
5. When repository access is prompted for set up, click No to auto-add the SSH key.
6. Type the name of the branch which includes your project’s configuration — master, for example — then click Next.
7. Wait while Bitrise is validating your project.
8. Select the .ipa export method. You can modify it later – for now, select development. This particular step requires your attention more. Once you click it, you should see your:
   • Project or Workspace path
   • Scheme name
   • .ipa export method
   • iOS stack
9. Submit a webhook at the request. Thus, Bitrise will activate a build at pushing or upon a pull request. This action also starts your initial build – the message will redirect you to the build page.

So, now you have the first app added to Bitrise.

Specifying the workflow

Depending on your app, one or two workflows are automatically initiated when you add a new app on bitrise.io. Those are the primary and the deploy workflows.

• The primary workflow is automatically initiated when adding a new app. Once adding the app is done, Bitrise triggers the app’s first build automatically: this build runs with the primary workflow. It’s not the same for every app you create: it contains different steps depending on the project type. This default workflow allows you to clone your app from the repo, install CocoaPods/Carthage if needed, run your app and your unit/UI tests.
• The deploy workflow is automatically initiated when adding a new app with tests configured in your app. It is similar to the primary workflow in the following ways:
  • It has the same basic steps
  • Its specific steps depend on the project type

You can start builds on Bitrise by:

• Manually starting one
• Scheduling one for a specific time
• Triggering them automatically by specifying a trigger event

Triggering builds in Bitrise

This part of the process requires our particular attention as there are multiple ways to manage triggering for the builds, such as:

1. Builds are activated with an identified trigger event and a workflow.
2. Setting up numerous or extra triggers and deleting the already existing ones is possible at any moment. By default, every new app you add will have two triggers:
   • one of them triggers a build every time code is pushed to ANY branch of your repository
   • Another one triggers a build every time a pull request is opened within your repository
3. You can also set a new trigger to run a specific workflow when someone tags a new version on any branch.
4. The triggers are available to manage in the Workflow Editor’s Triggers section. This action is also possible through direct editing the bitrise.yml of the app.

How deployment works

We need to have two workflows for deployment: first for internal testers (QA team), using Firebase distribution service (dev-firebase-cd), and the second for client and AppStore release (prod-appStore-cd). We’ll study both of them.

Deployment for a QA team

Let’s start walking through the dev-firebase-cd workflow.

You need to have basic steps, then let’s see how we proceed with configuring for an appropriate deployment. Signing automatically on the projects seems to be a preferable way of managing the code. It’s therefore natural if our deployment workflow contains the “Automatic sign-in” phase.

Remove the “Certificate and profile installer” stage. The certificate and profile installer step is used while providing provision manually. On “Xcode Archive & Export for iOS,” select the “Automatic sign-in” option and choose the Automatic code signing method, where the Bitrise Apple service connection should be used for automatic code signing.

You can choose: api-key or apple-id

• api-key – Connecting to an Apple service (such as the App Store Connect or the Apple Developer Portal) with the API key requires that you first add your Apple service authentication data on the Apple Services Connection page. Then follow up with an API key for your app. The API key authentication is recommended when connecting Bitrise to Apple Services. You can add multiple API keys to the Apple Services Connection page, whereas your project can use only one (selected in the Team tab).
• apple-id – Connecting to an Apple service (such as the App Store Connect or the Apple Developer Portal) with the Apple ID requires you first add your Apple ID and password on the Apple Services Connection page. Then you should select an app to use Apple ID authentication while the build is running. If you cannot use the API key authentication, I recommend using this option. Remember that you can only link one Apple ID to Bitrise.

Also, in this step, you need to opt for “Distribution method” development.

Add the “Set Xcode Project Build Number” stage to the workflow. This step automatically increases your project’s build number to prevent conflicts.

Here, set the value of your iOS app’s bundle version in the Info.plist file to the selected version number. It’s a great way to keep track of versions when submitting bug reports:

• If there are multiple build targets in your IPA, they need to be of the same version number as your app’s main target has. If this is a case, you need to coun this step for your workflow for each build target: if you have, say, three or four targets, your workflow has to contain the same number of instances of this step;
• If targets have different version numbers, you cannot submit the app for App Review or Beta App Review.

Configuring the phase. Specify the file path to the `Info.plist` file in the `Info.plist` file path input. Add a value in the Build Number box. This puts the CFBundleVersion key to the defined value in the Info.plist file. Hence, we have $BITRISE_BUILD_NUMBER Environment Variable as the default value.

You can add a value in the Version Number input if desired. This will position the CFBundleShortVersionString key to the specified value in the Info.plist file. However, this input is not essential.

You can also offset your app’s build version numbers if you handled version tracking differently before for the same app: all you need to do is set the value added to the build number. The value can be either a fixed integer or an Environment Variable.

Suppose you have an app and run its fifth build on Bitrise soon. You’d like to offset the build number by six as the app had six builds before using Bitrise.

For instance, if you have a project and its Info.plist actual settings are:

• Bundle-Version: 6
• Bundle-Version string, short: 1.2

…and your workflow contains the Set Xcode project build number step with the next setup:

• Build Number: $BITRISE_BUILD_NUMBER
• Build Number Offset: 6
• Version Number: 1.2

Given this, your first build on this app ($BITRISE_BUILD_NUMBER == 1) will be added to the Build Number Offset. Hence, the first build versions will be 1.2 (7) and the like.

Set “Extracts Xcode project info” data to environment variables. This step will just extract Xcode project information (Version and Build) and export them into environment variables prefixed with XPI_. You just need to set the relative path from the Source directory to Info.plist file. Source directory is considered the root directory created by the Git Clone step.

Let’s say your Info.plist file is in RootDir/ProjectName directory. Consequently, you should place this input to ProjectName/Info.plist.

We also use the “Stamp AppIcon with version number” stage to efficiently work with app versions throughout the testing. This script will apply ImageMagick to stamp the version number to all icons. Stamps version “version (build number)” sets to the bottom of the icon.

Set “Firebase App Distribution.” This is a great option to upload app binaries to Firebase, attach release notes, and specify testers you’d like to notify. In the workflow editor, add the “Firebase App Distribution” stage. Then follow the instructions below (showing where to get values for the required input variables):

1. Firebase Token. Install the Firebase CLI if you haven’t got it yet.
To Use the CLI with CI systems, login into the Firebase and get a token ($ firebase login: ci).

Once the authentication process is complete, your token is published on the console. (Example token: 1/a1gqPSI3ryNcsDiZnCaHnY-hg9u9nJeosz3iNPe-S- RLdmqdypiJMOjoeOhOGsWK).

Now, open the Workflow Editor Secrets tab and add the given as a new Secret Environment Variable.

2. App Path. Select a path to the file you want to upload.

Note: If you go with default values, keep in mind that $BITRISE_IPA_PATH (iOS) are paths to the latest file.

3. Firebase App ID. Log in to the Firebase console, select your project and navigate to Project Settings ( //auto-install script for Mac OS or Linux users: $ curl -sL https://firebase.tools | bash)

The General tab will contain your App ID.

For now, we’re done with the input variables. There’s only App Distribution to activate for the project on Firebase.

Pick your project and click Get started. This allows us for testers to manage, providing access to distributions. Upon triggering a build and successful upload, you’ll see your app binary on the list.

There is only one job to do before running your workflow: Code Signing. Simply follow the instructions on the “Code Signing” tab in your Workflow Editor to see how fun
and easy it is.

So workflow dev-firebase-cd is already configured, and you can also add more steps like “Send a Slack message” or another step.

Deployment for client and AppStore release

Now, let’s see how to set up the “prod-appStore-cd” workflow.

1. Initiate a new workflow based on “dev-firebase-cd.”
2. Change “Distribution method” to app-store in the Xcode Archive & Export for the iOS stage.
3. Remove “Set Xcode Project Build Number” and “Stamp AppIcon with version number” steps, no need for these for release deployment.
4. Firebase App Distribution step replaces Deploy to iTunes Connect — Application Loader step to authenticate the iTunes Connect account. Please ensure that the IPA path or the PKG path input has a valid value. The default value is perfect for the majority of cases since it points to the output generated by the Xcode Archive Step.
5. Specify your connection depending on the authentication method you’d like to use:

Use a previously configured Bitrise Apple Developer connection: Set the Bitrise Apple Developer Connection to automatic (the default setting), api_key, or apple_id.

Provide manual Step inputs: Add authentication data depending on which authentication method you wish to use, either Apple ID or API key authentication. Set the Bitrise Apple Developer Connection to off. Employ only one of the authentication methods:

• • For API key: Provide your API Key: URL (for example, https://URL/TO/ AuthKey_something.p8 or file:///PATH/TO/AuthKey_something.p8) and the API Key: Issuer ID inputs.
  • For Apple ID: Apply the Apple Developer connection based on Apple ID authentication. If you haven’t added any app-specific password to the used connection, the Apple ID: App-specific password Step input will be used. Other authentication-related step inputs are ignored.

Unless you use any dependency tool like CocoaPods or Carthage, the most critical steps in the workflow should look like those above.

Now, you are ready to deploy. Start running a new build by clicking the “Start/Schedule a Build” button from the app detail.

Hopefully, my guide on the deployment of an iOS application was helpful, and from now on, the process will be simpler for you.