SaaS web developers have it so easy. Their app is delivered from their servers directly to the browser, so all they have to do is write their code and merge it on whatever schedule they determine. Chrome and Safari have no power to reject their new release and users don’t need to install anything, so the newest update is up and available for everyone without a single delay. Voilà! (Or, sorry, web engineers… pretty much voilà, we know it isn’t quite so simple as that.)
Mobile release management, like release management for any kind of native app, is significantly more complicated than releasing to the web — a reality that is not acknowledged nearly enough. The mobile release status quo is rarely good enough in most organizations, causing unnecessary stress and added work for engineers, yet it is too often treated as an afterthought that’s already been solved.
In this post, we’ll take a concrete look at all of the steps that compose a typical mobile release pipeline and we’ll explain the importance of each. By the end, you may start to recognize the relative strengths and weaknesses of each step in your team’s current process, or come to realize you are lacking some steps entirely.
A note on mobile release styles
Most teams adopt one of three styles that define their mobile app releases:
Feature-based — Some particular set of features is designated for a given app release, and that release only goes ahead when all of the associated work touching that feature is ready to ship. If the features take one week to be built and verified, you’ll roll out the release in a week. If it takes three weeks, your release will ship in three weeks. This approach is usually taken by agencies and smaller orgs.
Time-based — A variation on the above in which developers ship feature updates at specific, planned points in time. The team must adhere to strict deadlines to ensure features in progress are completed, so that releases can ship on schedule. This makes it easier to coordinate and prepare for releases with marketing, public relations, and customer support teams, but also means it’s a problem if the schedule slips since it impacts the coordinating work done by these teams.
Release train — App releases happen on a fixed schedule and aren’t held up for any feature work; whatever code happens to be ready and merged by the time the release is cut will go out and any pending work will need to wait for a subsequent release.
There are advantages and disadvantages to each, and a team’s choice will depend on their size and the kind of app they build. Read our blog post comparing mobile release styles to learn more about each of these approaches. Though release style affects when the release process kicks off and how to determine when feature work is ‘done’, the larger process of preparing and releasing your app to the stores will be very similar with each.
The steps of mobile release management
Planning the release: Clear communication and documentation is required
Unless you (or someone else on your team) manages each and every release, you need to thoroughly document your process to ensure that anyone overseeing the release process understands all the steps that need to happen in order for your release to go out on schedule. It’s not uncommon for members of the mobile team to take turns managing releases in a rotation, and months can sometimes pass in between those turns. Going in semi-blind, without any guidance, is a recipe for slowdowns, problems, and frustration.
This document needs to be more than a one time thing that’s written up and left on Notion for everyone to forget about. It needs to be continually updated. In fact, the first step of any mobile release should be a retro about the last release that dives into how well (or poorly) things went, giving your team the opportunity to refine the process and its documentation to ensure the next release either goes better or is done equally as well.
Release branching: Get the process going
The next step in the mobile release process is the one which brings a release into existence: release branching. When starting a release, teams should be isolating production-ready code from any code still under development. This is often accomplished by creating a dedicated “release branch” for each release.
In some cases, teams will use their “master” branch as a snapshot of the code slated for production, while continuing everyday development on a separate development branch. Accordingly, when they’re ready to prepare for a release, these types of teams will promote the code intended for release from development to master.
In either case, by isolating production-ready code destined for an imminent release, you limit changes to code that’s about to ship (de-risking the release) while allowing other development to continue in parallel. Generally, only small additions or fixes should be merged into the release branch, while developers working on bigger changes or unrelated features can continue merging elsewhere. Usually this distinction is safeguarded more formally using branch protection. Post-release, the use of release branches also allows teams to more easily push hotfixes without pulling in lots of unrelated, new code that has been merged in the interim.
Read our post about choosing the right branching strategy if you want to learn more about your options here.
Continuous Integration & Continuous Delivery (CI/CD): Build, test & distribute
Continuous Integration (CI) — Build and test
With a release now defined and its code isolated, the team needs some way of validating any changes to the code in the release branch. Enter Continuous Integration (CI).
CI is the practice of regularly merging changes into shared code, and then automatically building and testing the result. It is usually leveraged throughout the mobile app development cycle, but during releases it is especially valuable because the cost of inefficiencies and mistakes is higher. CI allows teams to collaborate on and finalize releases with more confidence, by catching any conflicts or integration errors that arise during merges into the release branch.
A robust CI setup further improves stability through the app release process by standardizing the build environment across each build. Whether for iOS or Android, release builds require a specific configuration (build settings, provisioning profiles, signing certificates, etc.) and a consistent integration environment; if these requirements aren’t met, flakiness and risk increase. Often teams turn to third party, cloud-based CI services which take care of spinning up consistent, reproducible integration environments. Such services also manage the hardware behind the build servers, which can be cumbersome to set up and maintain in-house (iOS integration servers are especially tricky, with unique hardware and operating system requirements).
Generally, teams should set up their CI pipeline to build and test on their release branch any time code is committed to the branch. Most CI platforms offer integrations with version control systems (e.g. GitHub) to handle this automatically.
Continuous Delivery (CD) — Distributing a Release Candidate
Continuous delivery (CD) describes the process of automatically generating and distributing a build (usually for testing) after each successful integration with your base branch. Most cloud-based CI services also cater to this CD step, and many leverage developer tools like fastlane to help connect the pieces of the CI/CD pipeline.
An important rule enforced by most distribution destinations (including TestFlight and the App Store for iOS, and Google Play for Android) is that no two release candidates can have the same version number and build number. This means build numbers must change with each new release candidate the CI/CD pipeline delivers. This incrementation can be done manually, but it’s often executed automatically as a step in the team’s CI/CD workflow.
Testing the release candidate
Testing should be undertaken throughout the app development process, but testing of a final release candidate is especially crucial. Because mobile releases can’t be rolled back or hotfixed easily (unless you use Runway’s Rollbacks feature and hotfix automations), teams should do their utmost prior to shipping to ensure that new code functions properly and that no other areas of the app have broken as a side effect of changes.
Because the mobile app team itself is so close to its product, team members are inherently biased and it can be more difficult for them to spot bugs or areas of friction for users. For that reason, during testing it’s very valuable to put release candidates in front of an audience that’s further from the product. This lends itself to gathering more open-ended feedback in addition to basic bug reporting. Distributing builds to a controlled group of users for testing in this manner is referred to as “beta testing”.
Internal beta testing
A release build is distributed to a group of users within the company. These are people that are familiar with the overall product but may not use the app on a regular basis. Internal beta testing also promotes transparency, because it keeps the rest of the company in the loop on new features and changes to their app. Read more about pre-release build distribution.
External beta testing
A release build is distributed to a pre-selected group of users outside the company. These users may be sourced from an internal list of “power users”, or randomly selected from your general user base. External testers have the least insight into the inner workings of your company and will therefore provide the least biased feedback, and generally interact with the app in the most “real world” way. Learn how to set up your own external beta testing program.
Dogfooding
Dogfooding is a specific subcategory of internal beta testing: users inside the company who are otherwise regular users of the (production) app, or a competing product, use the release build for its intended purpose. Instead of testing contrived flows, they use the app just as they otherwise would. Dogfooding is used heavily by teams at Microsoft and Google where, for example, developer tools they make can be used by their own development teams.
Regression testing
Regression testing entails execution of a set, or “script,” of specific functional tests on a release candidate. Usually these scripts are designed to cover core and critical flows in the app (e.g. sign-in, or checkout in e-commerce) to make sure they haven’t been unexpectedly affected or broken by changes in the release. Regression testing can be carried out manually, usually by quality assurance (QA) analysts on the team, or automatically, with UI testing on virtual devices or via automated device farms.
Feature flags
Testing can’t catch every problem with your code, which means you always run the risk of shipping a broken feature that will cause unintended issues, or even crash your app for some users. Feature flagging provides additional peace of mind, because it makes it possible to release even WIP code safely — regardless of if your tests immediately and thoroughly catch every single issue that might come up. You can put more confidence into shipping new code because any work you introduce can be reliably hidden and deactivated behind a feature flag until you’re ready to roll it out to more users.
Metadata, release notes & screenshots: App Store and Google Play presence
With every release, both the Apple App Store and the Google Play store allow teams to share release notes, update their app screenshots and videos, and modify various other aspects of their store presence (e.g. description and search keywords). Choices here can affect your app’s visibility in search results and its appeal to prospective new users.
With more and more users opting into automatic app updates, you may feel that it’s not worth spending much time or effort on release notes and screenshots. For example, some time ago Facebook controversially chose not to write descriptive release notes. Others maintain that more involved release notes and screenshots are an extension of the app’s branding and can offer an additional channel through which to connect with and excite users, showing you have such depth of commitment to your product that you engaging with users even at a level where they might most often expect to encounter something empty and mundane.
Approvals
Many mobile app teams have an additional “gate” in their release process that calls for sign-off by one or more stakeholders. In some cases, this is as simple as a final “O.K.” from the overseeing parties. In other cases, a more involved audit takes place (e.g. security or privacy compliance). Often this entails some combination of release build, code diff, and changelog being packaged up and delivered to a different team within the company, or to an external partner.
Submission & app review
Upon successful completion of all of the preceding steps, the team is finally ready to submit the app! The final release candidate build is uploaded to the store, the metadata and screenshots are added in, and the finished product is packaged up for subsequent review by the store’s moderators.
Turnaround time for app reviews can vary from hours to days to weeks, and rejection is not uncommon. In 2022, Apple rejected 28% of submissions; Google (which doesn’t share this information publicly) rejected some unknown, but certainly significantly smaller, amount. The potential reasons for rejection are diverse, and even experienced teams with an established store presence have to be prepared for occasional rejections. Some app rejections will require the team to address issues in the build and restart the entire release process from the beginning. Others just call for changes to metadata, or answers to questions from the review team.
Assuming all goes well and the app is approved, teams have options for how to release the new version to their users. Apple and Google both support immediate or phased rollout styles, with phased rollouts providing an easy way to slowly release your app to an increasingly larger percentage of users while you monitor your app post-release to keep an eye out for any problems you may have inadvertently shipped.
Monitoring your app post-release
When is your app most likely to start crashing? Immediately following a release. When is user behavior most likely to change? Immediately following a release. When is the release process over? Not until you’ve verified that it’s stable for all users and not negatively impacting your company’s bottom line in some way.
The range of what teams monitor varies from the fairly straightforward (crash rates) to second order effects that may not be as obviously tied to the release (like a notable drop in daily active users). As noted above, monitoring is often done in tandem with a multi-day phased rollout. It’s better to catch a problem when it’s impacting only 10% of users vs when it’s impacting everyone.
Some common things to look out for:
Stability — What percentage of user sessions are stable vs the percentage that lead to a crash? You likely want this to be high as a rule, probably over 99%, and a release that sees your stability fall beneath whatever percentage you determine is one that should be quickly investigated.
Sign-ups — Are sign-ups dropping post release? If you’ve been around for a bit, you should have a good idea of how many sign–ups you tend to get on a Wednesday or a Saturday or just averaged throughout the week. If you deviate from this, you might have broken something.
Daily active users — Same as with sign-ups, you have an expected range of users interacting with your app on a daily basis. If this falls off, then something probably isn’t right — unless it’s New Year’s Eve or something. And if it is, what are you doing releasing new updates on New Year’s Eve when you could be sleepily counting down the seconds to midnight?
Daily expected revenue — Does your app have a cart, or prompt users to make any sort of purchase? It’s a good idea to keep an eye on revenue to ensure it doesn’t fall outside of your normal range. (And if it happens to break out above the usual range while you’re keeping an eye on it then you can celebrate.)
Not all of the examples above could be related to a bug. There may be a UX design issue or other change that simply altered user behavior in a negative way. But just because an issue isn’t being caused by a coding error doesn’t mean that it’s not the team’s responsibility to catch it and find a way to resolve it.
Confident, thoughtful mobile release management means less friction and stress when shipping your releases
The full mobile release process is quite involved and there are many dependencies and potential blockers between steps in the process. Tools and team members involved in any one step can often be siloed from those involved in other steps, preventing the existence of a source of truth and making it difficult to monitor the state of a release at a glance. Careful coordination and effective collaboration is required, and it must occur across disciplines: throughout the app release lifecycle, engineers, product and project managers, designers, QA analysts, and stakeholders external to the team or even the company are all called upon.
Every company and team approaches mobile release management in their own slightly different ways. Now that you’ve read this guide, take a look at how companies like DoorDash and Mercari approach their own mobile releases. You’re not alone in trying to discover the best way to tackle releases for your own team.
