A Successful Mobile Release Strategy, Part 1: The Build Pipeline

Introduction

The Bitrise Mobile DevOps Assessment report shows that app store ranking and customer ratings strongly correlate to app release frequency. Speed to market and customer confidence that new versions will bring improvements are crucial. However, achieving this requires implementing many technical and business processes that are challenging and complex.?

During my time at AND Digital, I’ve supported a number of clients in implementing such a mobile release strategy. In this two-part article, we'll look at the steps a mobile development team can take to successfully release a high-quality app to its customers. We’ll focus on a team who have chosen React Native to build a cross-platform app for iOS and Android. However, the majority of the learnings can be applied to app development using any approach, native or cross-platform.

In this first part, we will look at the technical processes that are needed to automate the build and test of a React Native app.?

Build Pipeline

The technical build pipeline is at the heart of any mobile app delivery process. This is a set of systems and software tools that take code written by developers, run a number of automated checks and tests to assure quality, and then produce an artefact that can be installed and used on a real device.

React Native* is a popular framework for app development. It is a cross-platform solution for creating iOS and Android apps using the React framework. This allows developers to write applications once in a single codebase and then compile them for both iOS and Android.

To construct a build pipeline for a React Native app, you should consider using the following (or similar) tools;

• GitHub. A platform used for version control of an application codebase and facilitates collaboration between developers.
• GitHub Actions. A continuous integration and continuous deployment (CI/CD) platform to automate building, testing, and deploying workflows directly from GitHub repositories.?
• BrowserStack. A cloud-based platform that provides access to a wide range of mobile devices for remote testing.
• Slack. A collaboration platform, used to share the build and test status of the pipeline.
• ReportPortal. An open-source reporting tool for software testing that provides comprehensive and visual reports.

It is a good idea to split a large team (maybe one that two pizzas cannot feed) into different squads: small groups of developers, testers, and analysts. The Scrum methodology is also useful here, where each squad includes a dedicated scrum master and a product owner, and a team commits to delivering new product features at the end of each sprint. Multiple developers can all contribute to the codebase at the same time. Adopting GitHub for code management and the GitFlow branching strategy allows multiple features to be built, tested, and integrated concurrently.?

The following diagram illustrates how feature branches - where new functionality, fixes and improvements are built - can be integrated into the develop branch using a build pipeline.**

This process starts with a feature branch being pushed to GitHub and a Pull Request (PR) opening. This allows developers to review code, leave comments, and request changes if necessary.?

Opening a PR should automatically start the build pipeline, where several tasks are automated.?

• Typescript Checks. Transpile Typescript into Javascript and identify any type errors in the code.
• Code Linting. Static code analysis to identify and fix potential errors, stylistic inconsistencies, and suspicious patterns in the code.
• Component Tests. Run the Jest suite of unit and component tests to identify if a change has introduced any faults into the app.
• Compilation for iOS. Build the application for iOS, injecting pre-production environment variables so the app does not interact with production systems. Use an Ad Hoc Distribution Certificate to sign the application so it can be installed on test devices for testing, without needing to be distributed via the App Store. Produces an .ipa artefact file.
• Compilation for Android. Build the application for Android, injecting pre-production environment variables so the app does not interact with production systems. Use Android Self-Signed Certification so it can be installed on devices for testing, without needing to be distributed via the Play Store. Produces an .apk artefact file.
• End-to-End Tests. Install the .ipa and .apk files on real iOS and Android devices remotely using BrowserStack. Launch the app, and execute the end-to-end tests to prove that key flows can be used by interacting with the application user interface, as a real user would.
• Build Status Notifications. Use a Slack hook to post a message into a specific channel with information on the build status.
• Test Outcome Reports. Upload the test reports to the ReportPortal for further analysis and tracking over time.

If all checks, tests, and build steps pass for a PR, and it receives the necessary approval from developers during code review, it can be accepted. This final step in the process can also be automated. However, it is often the case that a team prefers a developer to do a final sense check before accepting the PR, requiring the developer to click the “Merge pull request” button in GitHub and manually complete the integration of the feature branch into the develop branch.

Preparing the Production Apps

After a sufficient number of features have been developed during a sprint, a Release Candidate (RC) can be created. This is a build of the application for iOS and Android that interacts with the production backend systems and is distributed through the beta testing channels of the App Store and Play Store. This will allow the team to smoke test the application and perform a number of final checks and assurance tests to ensure the application performs as expected in the real-world environment in which customers will eventually use it.

Here, the build pipeline will aid the team once more.?

First, a release branch should be created from the develop branch. This release branch will include all the features made throughout the last sprint. These branches are short-lived and are mainly used to apply any final configuration changes, such as incrementing the application version number, and to sign the application with production certificates. Once this release branch is pushed up to GitHub and a Pull Request is opened, the same steps as used for integrating a feature branch into develop are followed to merge the release into the main branch.

Once the release branch is merged into main, and back into develop, a production build of the iOS and Android app can be created. The end goal of this part of the build pipeline is to have the app ready to be submitted for review by Apple and Google ahead of publication on the App Store and Play Store.?

Some of these steps can be automated; however, there may also be several manual actions that squad members perform directly themselves.

A number of tools and systems are needed to accomplish this.

• GitHub Actions. A workflow injects production environment variables, and then two subsequent workflows sign the application for production distribution.
• Google Play Console. Google’s administration system to manage applications published through the Play Store. The.apk file from the GitHub Action workflow is uploaded to the Google Play Console directly.***
• App Store Connect. Apple’s administration system to manage applications published through the App Store.
• Transporter macOS App. A macOS application for uploading content to App Store Connect. The .ipa file is downloaded from the GitHub Action workflow and uploaded to App Store Connect. Note: the Transporter app must be used at this stage as App Store Connect does not support the direct upload of content via its web interface.***
• Google Play Internal Testing. A system for beta testing via the Google Play Console, to distribute production-like builds to real devices without the need for Google approval. Test users are invited to the beta channel and are notified of a new build via email to install and test.
• TestFlight Internal Testing. A system for beta testing via App Store Connect to distribute production-like builds to real devices. The Internal Testing option can be used to avoid needing Apple approval for testing, requiring testers to be added as users directly in App Store Connect. Testers are then notified via email of a new build to install and test the app via the TestFlight iOS app.

In part 2 we’ll look at how to submit apps for review by Apple and Google, using gradual rollout systems, monitoring releases, and the team processes necessary for each squad to reliably and consistently release updates each sprint.

Footnotes

*Note: For more information on how to migrate to React Native in your organisation, please read my article Building a React Native Capability below.

**This article focuses on how to use GitFlow as a branching strategy. However, it should be noted that many mobile development teams now prefer a trunk-based approach to version control. This method simplifies branching rules by allowing features to be merged directly into the main branch, unlike GitFlow. Despite the shift toward trunk-based strategies, GitFlow remains a reliable option and has been beneficial for the projects I worked on that utilised Visual Studio App Center before transitioning to GitHub Actions. App Center only allows one build configuration per branch, which posed challenges when different application signing credentials were needed for testing and production. The pipeline outlined in this article illustrates how to build and sign branches for pre-production testing, while the main branch is built and signed for production. In contrast, GitHub Actions workflows do not have this limitation, enabling separate configurations for a single branch (like main) using different signing certificates. Furthermore, with Microsoft planning to retire Visual Studio App Center in March 2025, now is an ideal time to consider adopting a trunk-based branching strategy for mobile application development.

***It is important to note that both Google and Apple provide APIs that can be used to automate the delivery of Android and iOS artefacts to the Google Play Console and App Store Connect. Additionally, CI/CD tools like GitHub Actions often include useful plugins to streamline this process. However, this article focuses instead on how to deliver artefacts manually by downloading them from the CI/CD tool and uploading them directly to the Google Play Console and App Store Connect.?