What is mobile release management? Why does it matter?
If you had Googled âmobile release managementâ way back in 2021 or even 2022, itâs unlikely anything specific to the term would have come up. That has changed rapidly over the past couple of years, and now youâll find articles by mobile teams like DoorDash and Squarespace detailing how they manage their own mobile releases, video explainers of what mobile release management is all about, and several products offering features and tools to support your mobile release processes. Â
The term mobile release management has only become relevant so recently because itâs also only recently that there are specialized platforms and tools available to provide broad support for every part of the mobile release lifecycle. In the earlier days of mobile development, engineers had no choice but to build out tooling and infrastructure themselves, as time allowed and as problems arose. This was ad hoc and not part of a coherent strategy, making your mobile release process unscalable, difficult to maintain, and nearly impossible to replicate from team to team to team.
But that ad hoc era is coming to an end. Mobile teams need holistic solutions for managing their release cycles, instead of cobbled-together, Rube Goldberg style scripts and processes that can cause as many new problems as the old problems they were built to solve. The more you play it by ear with fixing your current release process â or building an entirely new one â the less successful youâll be in making it all work. Â
Key Features
To find the right solution for your teamâs mobile release management, you need to consider your unique needs and goals when it comes to automation, visibility, and collaboration throughout the release process, and look for integrations that will allow a solution to connect easily and comprehensively with the rest of your stack. How much of your release process can the solution automate? Does it give your team a reliable single source of truth to see release progress and history? Does it connect to all your tools to keep your team from needing to jump from tab to tab to Slack to tab just to manage a release and get it out the door?
End-to-end automation
Releases involve a steady drip of manual tasks that waste more time than you might realize â especially when your team releases frequently. So many of these tasks exist beyond the reaches of CI/CD (think rollouts, Git wrangling, approvals, release notes and comms, etc.) and they can sneakily eat up a whole dayâs worth of your mobile teamâs time each and every week. An excellent mobile release management platform or process should provide end-to-end mobile release automation, eliminating manual work from before kickoff all the way to the end of your rollout (and even the occasional rollback). From branch cuts and cherry-picks, to App Store Connect and Play Console management, to app health monitoring and phased rollout controls, no part of the process should be left out. Ideally, youâre able to run an automated, scheduled release train that requires no manual work on the part of your team, aside from building the features that make it onboard each release train.
Visibility
With mobile release management, the goal is to get as close as possible to creating a single source of truth so that the entire mobile team and everyone else in the organization who has a vested interest in the mobile app can get on the same page â and stay there. By increasing transparency throughout the release process, your team should waste less time asking and answering the same questions over and over in Slack, and improve confidence in app releases (with a corresponding increase in quality). Â
Collaboration
Mobile releases involve a range of different tools and require collaboration between a variety of team members. But only certain subsets of team members have access to certain subsets of tools, and itâs nearly impossible to get a clear and complete picture of where everything stands both within each release and across multiple releases. This often leads to the bulk of release work falling on the shoulders of the select few (which could be only one person in many cases) who understand the full range of steps involved in releasing an app update. Mobile release management aims to make the process less mysterious so that stakeholders from across the org can contribute to running the release. Â
Integrations
To be able to provide end-to-end automation and create a real single source of truth, a mobile release management solution needs to bring as much of your existing release toolchain as possible into a unified platform â from version control, to project management, to CI/CD, to the app stores, to crash reporting and analytics tools, and more, with scoped access and role-based responsibilities so that folks can see exactly when and where in the process their help or input is needed.
Runway
The first solution on our list is arguably the only true mobile release management platform currently available: Runway. We know that may sound biased, given this is a Runway article on the Runway blog, but what separates Runway from other solutions is that it allows you to automate and manage the entire mobile release lifecycle in an end-to-end platform, whereas other tools are point solutions that only touch a limited slice of the release process. Runway is involved long before you even build your first release candidate and long after the new version is live in the app store. Â
This is not meant as criticism of the other tools in this post; supporting the entire mobile release process isnât necessarily their goal. As youâll read shortly, mobile release management is a secondary feature of those other tools, an add-on meant to support some part of their core functionality. Mobile release management is our core functionality and the singular focus of our entire team.
Runway is tooling- and platform-agnostic, integrating with every piece of your mobile toolchain and helping you ship to all the different destinations you might need to ship to. It doesnât matter which CI/CD provider, monitoring and crash reporting software, version control system, communication platform, project management tool, and other solutions you use â Runway almost certainly integrates with them, bringing everything together into a unified control center so you can manage and make sense of everything in one place, and have off-the-shelf automations that run on top of them and extend their functionality. Â
What makes Runway unique (and sets it apart as the only mobile release management platform) is how it hooks into and brings together every single step in the release process. From planning the upcoming release in issue trackers like Jira and Linear, to managing your builds in CI/CD, to tying all your commits and PRs to ongoing release work, to keeping everyone notified as to whatâs going on via Slack or Teams, to running your regression testing, to managing approvals, to getting fixes in, to uploading all your metadata, media, and binaries to the App Store and Play Store, to monitoring and taking action on crash reporting and release health during your rollouts, Runway acts as the glue that ties the disparate parts of the release cycle together.
Bringing everything together in this way allows Runway to 1) act as a single source of truth that provides full visibility into the release process while supporting better collaboration, and 2) enable end-to-end mobile release automation, eliminating most of the manual work that happens from kickoff to rollout.
But even if Runway is the only mobile release management platform, that doesnât mean other tools donât offer some release management functionality of their own. Â
Instabug
Instabug is a mobile-specific crash reporting and monitoring platform that helps engineers track, discover, and fix problems related to app health. As you might expect based on that description of their core product, their features related to mobile release management focus on just the rollout part of the release cycle. A better name for what they offer might be mobile rollout management.
Much like Runway, Instabug integrates with App Store Connect and Google Play Console so that you can control your rollouts from within Instabug, incrementing or pausing rollouts from their dashboard instead of from Apple and Googleâs interfaces. You can keep an eye on rollout progress, seeing exactly what percentage of users are receiving your update alongside Instabug stability data and user reviews about the new version being rolled out. You can also set automated thresholds that will pause or accelerate a rollout based on Instabugâs crash reporting and stability data for the release.
What keeps Instabug from being a complete mobile release management platform? Â
They donât support anything except rollouts. As noted above, Instabug doesnât support any part of the process that happens before you hit âreleaseâ and they support a limited slice of what happens afterwards, aside from providing tools to leverage crash data captured by their own product. Â
Their rollout features are limited. Since Instabug doesnât connect to any other part of your release process or stack, there are gaps in what you can actually do around rollouts. For example, they donât have a way to quickly spin up a hotfix from their rollouts dashboard, and they provide no option to easily roll back an unhealthy release.
They are Instabug-only. Instabugâs rollout management is only for Instabug users and it uses only Instabug data. Because they donât integrate with other kinds of tools that your team uses to measure app health (e.g. product analytics tools like Amplitude or Mixpanel, or other observability tools like Datadog), you canât monitor or automate rollouts in a comprehensive way.
So, if youâre already using Instabug for your appâs stability monitoring, their rollout-related features provide an additional set of functionality that you can take advantage of in addition to their core monitoring offering. If youâre not already using Instabug, then it canât do much for you.
Bitrise
Like Instabug, Bitriseâs core offering is one specific piece of the mobile toolchain: CI/CD. This means their mobile release management tooling is like Instabugâs in that itâs built around their core competency (in this case, continuous integration and distribution), but instead of being rollout-centric, they are build-centric.
Bitrise aims to provide assistance in getting your build from the point where youâre creating a release candidate to the point where youâre uploading your binary to the stores. Instead of connecting with the existing tools in your release workflow to support your entire process, they are entirely focused on extending their own core services to build upon and automate the steps in your release cycle that touch or are involved with CI in some way. If Instabug is focused on the end of the cycle, then Bitrise is more focused on the middle.
What this means is that theyâre able to provide notifications when either manual or automated actions are taken in Bitrise, set an approval process so that tasks must be officially marked as done before a release can go out, assist in uploading screenshots, release notes, and other metadata to the stores, and then allow you to control rollouts from within Bitrise, though without the crash and other app health context or related automations provided by the first two services on this list. Â Â
What keeps Bitrise from being a complete mobile release management platform?
Designed for people who spend a lot of time in CI. Bitrise isnât so approachable for less technical contributors to releases, and not all that intuitive even for folks on the mobile team who donât spend much time dealing with CI.
Itâs build-centric. Bitrise gets you from generating your build to some store steps, but is lacking in features that arenât directly connected to CI/CD. Their integrations with other platforms are limited, their rollouts offering is immature, and their pre-build support does not exist.
Itâs Bitrise-only. Use GitHub Actions, Circle CI, Azure Pipelines, or any other CI/CD platform? Then you canât currently use Bitriseâs solution.
It doesnât provide full visibility into your process. Since it does not connect with all the other tools in your release workflow, there is no single source of truth and managing your releases will continue to mean jumping from tab to tab to tab.
Support for iOS and Android is unequal. Some features are iOS-only, like submitting builds for review, and managing your beta testers.
No app health monitoring or related automations. Though you can pause and resume  your rollouts from within Bitrise, you cannot pull in monitoring and health data to automate rollout management like you can with Instabug and Runway both. Â
The Bitrise approach to mobile release management is like putting a planeâs cockpit in its engines. Such a plane could probably take you between two points in the sky, but would likely crash during take off or landing.
Build it yourself
Do you like Ruby? Can you build a web frontend? Well then, do we have a side project for you. Â
Libraries like fastlane and a slew of APIs for the various tools your team uses throughout the release process make it possible to build out your own mobile release management platform. Most of what weâve described above is something you could achieve at least some limited version of on your own. Most teams are already building something to help them manage their releases, but a bit of scripting here and a written checklist there isnât mobile release management. At best, itâs mobile release whack-a-mole. Â
Taking a DIY approach to actually building your own bespoke mobile release management solution has many drawbacks and only a very few âeliteâ engineering orgs (e.g. Etsy, Shopify) have managed to build out internal platforms that even come close to a complete solution. And those that have wouldnât necessarily do so again.
Resources
Someone has to plan everything out, build the automations and scripts that will keep the release process moving, and the frontend and backend that will house the unified platform for it all, and write out detailed documentation for other members of the mobile team to follow. This can and will take several months at least and is the sort of project that you could work on forever without ever quite finishing it, meaning you could end up with a half-finished process that metastasizes into more and more tech debt over time. Also, for most teams out there, release management and related tooling is not a core competency.
Opportunity Cost
If these resources (time and people alike) were spent on the product instead, what business impact could that have? How many more features could you ship or update every year if engineering hours arenât being split between product work and releases? Â
Maintenance
Things change. Apple and Google update their developer portals. Scripts stop working. Processes become outdated and slow. Someone will have to keep on top of these changes and adapt your approaches to them or your release process will begin to hinder you as much as it helps you. Typically the engineers that tackle this kind of work are specialists who create significant bus factor, so upkeep and maintenance become particularly fraught areas of risk when it comes to projects like this.
User Experience
Creating your own bespoke mobile release process means making sure itâs intuitive enough that you can easily teach other people how to manage it. Without the user friendly interfaces and guardrails of third-party MRM platforms (which have to be usable enough for people to actually want to pay for them), youâll have to put in more hours and resources either getting people up to speed or better designing your own interface, which is more time sunk on internal tooling and less time sunk on the actual app youâre building.
Do nothing
You may not currently be practicing anything that weâd call âmobile release managementâ, or have much mobile release tooling in place, but your releases are still running, right? Sure, they may not be perfect. They may not always run smoothly. They may even stress out your team on a regular basis. But your app still gets updated and thatâs all that matters, right? How much harm is doing nothing really causing when it comes to mobile release management?
Wasted time and effort
The work that goes into releasing an app â wholly apart from all the work that goes into building that app â is significant. Each release likely takes several hours of hands-on management, with additional time required to monitor the health of the app after launch and get any necessary hotfixes out. A couple hundred hours of engineering time poured into release processes every year is a couple hundred hours that would have been better spent on building features that your users care about. Â
Costly bugs and poor app health
At some point, and probably at many points, your team will ship critical bugs to production. Because of the nature of mobile releases, even an issue that takes just a few minutes to fix can cause hours or even days of problems for users (and your business). How much revenue does your app bring in during those hours and days usually, and how valuable is it to put processes in place to make app health issues less likely to occur and easier to recover from when they do?
Bad DevEx and engineer burnout
Managing cognitive load as a mobile engineer can be tricky. There are numerous tasks â reviewing pull requests, rebasing your branch, updating your tickets, running releases, dealing with app store rejections â that all compete for their attention, with each task taking up some percentage of your teamâs mental bandwidth. A release process that requires tons of context switching, question answering, and cat herding can cause burnout, increase errors, and lead to a decline in productivity even as everyone looks busy running around doing all their tasks.
Your choice matters to your mobile team Â
Every company and team approaches mobile release management in their own slightly different way. Regardless of how they do it, mobile releases are always quite involved, with lots of dependencies and potential blockers between steps in the process. Giving your team the right tools to help them manage all the different pieces of work that go into each release can mean the difference between a bogged down, stressed out team that spends just as much time troubleshooting their workflows as they do building their app, and a happy productive one that ships more features and feels more confident in their work.