Get access to Runway today
We'll get back to you soon with your account details.
Got it! We'll be in touch.
Something went wrong while submitting the form. Try again?

Optimizing the mobile release process

As of early 2020, there are nearly 4.5 million Android and iOS apps available for download worldwide. To remain relevant within such a large ecosystem, individual apps need to continuously deliver value to their users. From building out new features, to supporting the latest and greatest OS changes (hello, Dark Mode), users expect things to keep improvingor, at the very least, to continue functioning properly.

In response, companies want to release more frequently than ever before, and a mobile app development team’s release process can quickly become a bottleneck within the overall app product cycle. Establishing good release practices early on can help alleviate some of this friction and set your team up for success in the long run.

In this blog post, the first in a series examining the mobile release process, we’ll look at all the pieces that need to come together when shipping a mobile app update. Over the course of the next few weeks we’ll dig deeper into each step of the process, comparing various approaches and identifying best practices.

Mobile deploys are uniquely difficult

If you’re part of a mobile team, you’ll know that there are particular requirements and considerations that go into mobile releases—whether it’s a brand new app, or simply an update to an existing app—especially when compared to releasing updates to a web application.

Mobile apps are different from web apps because they require the submission of a bundled binary: a packaged bundle of code that’s installed on a user’s mobile device and executed when the app is launched. Additionally, developers don’t always control their app’s method of delivery. New versions distributed to the general public must be uploaded and submitted to the store for the given platform.

Currently, mobile apps are mainly distributed in two places: the Google Play store and the Apple App Store. Here, Google and Apple respectively control the distribution of mobile apps, as opposed to websites which are not dependent on any third party for distribution. Both Google Play and the App Store have a formal review process, during which they can choose to reject an app update as they see fit. Developers must both meet the technical requirements and abide by the store’s rules (e.g. App Store Review Guidelines), or risk binary rejection. Review times vary in length from as quickly as a few hours to several days. This process adds uncertainty to releasing app updates, and further differentiates mobile releases from web deploys.

Software Access - Mobile vs. Web
Mobile releases rely on a third party for software distribution, which increases friction when compared to websites.

Once a binary is installed on a user’s device, there’s no guarantee that any future updates will also be installed. Although automatic updates have increased the likelihood that users will update to the latest version of your app, there often exists a long tail of old app versions that your team must continue to support. As a result, issues caused by a buggy binary can’t be fixed as quickly as they could be on a website, where your team directly controls how frequently new code is delivered to your user base.

This makes native mobile app updates inherently riskier; and for most app development teams, this translates into a higher standard of code quality for mobile apps than for websites. With all software, bugs caught in production have been found to be up to 30 times more costly to fix than those caught in earlier stages of the development cycle. For mobile apps, the increased overhead that comes with releasing updates means this value is probably much higher. Additionally, you can’t easily force your users to upgrade to a newer build, or “roll back” to a stable version, which means the lifespan of bugs out in the wild can be much longer than for websites, and the impact more severe.

Automating the mobile development process with CI/CD

Continuous integration (CI) is the release practice of automating the validation of new code so that it can be automatically deployed. Continuous delivery (CD) is the practice of automatically deploying new changes to a testing environment. Cloud-based CI/CD services can improve the reliability of the CI/CD step, because they guarantee a consistent build environment that’s defined by your unique specifications. Additionally, many cloud-based CI/CD services now plug in directly with your version control platform (e.g. Github) to verify code changes both before and after they are merged into the main development branch. 

Continuous deployment occurs when teams immediately deploy new changes to their production environment. For teams that have implemented continuous deployment on their web applications, deployments may happen as frequently as several times per day as code changes are merged into the main development branch. Continuous deployment of mobile applications has been a subject of interest for teams that are looking to completely automate mobile app updates and increase their frequency. Unfortunately, due to the fact that both iOS and Android apps depend on a third party to actually deliver software to users, continuous deployment of mobile applications is impossible.

That being said, by optimizing the various steps in the mobile release process, teams can get to an approximation of continuous deployment that’s better suited for mobile platforms. We’ll discuss continuous deployment, continuous delivery, and continuous integration of mobile apps in a subsequent blog post. We’ll also take a closer look at some of the most common steps in teams’ mobile release cycles, identifying some best practices and strategies for optimization.

More than DevOps: App updates involve many stakeholders

Mobile releases have many moving parts, spanning various disciplines. From building and distributing, to QA and beta testing, as well as gathering release notes and marketing content, a single release requires coordination between several groups within an organization. Engineers, product managers, QA analysts, internal and external testers, designers, copywriters, and marketing are often all involved. In some cases, additional stakeholders may want to remain in the loop on the progress of a given release, adding further complexity.

Towards a more agile mobile deployment process

For all of the reasons discussed above, mobile releases have lagged behind when it comes to continuous deployment compared to web. Even super efficient mobile teams with lots of in-house automation and tooling still only release app updates every week or so. But this isn’t necessarily a bad thing – mobile app teams must work within the constraints of their platform to deliver updates that are well-tested and high-quality as efficiently as possible. And while it seems unlikely that mobile teams will reach the same release velocity as web teams in the near future, there are still lots of ways that your team can make incremental improvements to the mobile release process that can increase the quality, velocity, and confidence of your releases.

Be sure to check out our upcoming blog posts to see how you can improve your team’s mobile release process and gain confidence in your releases.