Developing and maintaining a high-quality, engaging app already takes serious effort and time. But with ever-stricter requirements imposed by the Google Play and Apple app stores, even the release process has become a time-consuming and challenging task for mobile development teams. This issue has gained so much attention in recent years that it’s not unusual for companies to allocate resources and headcount for a dedicated release manager or Technical Product Manager (TPM).
What’s more, once a release is out, it can’t be rolled back. The risk can be mitigated somewhat with use of feature flagging, but shipping binary is still largely an irreversible exercise.
“It was the most terrifying thing to take 10,000 diffs, package it into effectively a bullet, fire that bullet at the horizon and that bullet, once it leaves the barrel, it’s gone. I cannot get it back, and it flies flat and true with no friction and no gravity till the heat death of the universe. It’s gone. I can’t fix it.”
Chuck Rossi, Facebook Release Engineer
There is no perfect, one-size-fits-all solution for mobile app releases, but there are a number of best practices and tools you can leverage to make things easier on your team. In this post, we’ll share some of the challenges unique to mobile releases, highlight typical mobile release models, and offer a few best practices to help you lower friction and ship updates with more confidence.
The mobile development challenge
Developing mobile apps is inherently complex. Besides the baseline application development work, you have to account for multiple screen sizes, locales, platforms, and different hardware, and backwards compatibility is a constant challenge.
While web developers also face some of these challenges, they never have to worry about getting updates approved by a third-party store or ensuring that users update their applications. Browsers and servers handle discovery and distribution automatically.
When developing for native mobile platforms like iOS and Android, the whole process for mobile releases is entirely different. Even minor hotfixes require you to build and compile a binary, upload it to the app store, and wait for approval.
Once your update is approved, you have to wait for users to install it. While most users have automatic updates enabled these days, there will always be some percentage who don’t, leading to additional challenges like backward compatibility and a need for versioned APIs and forced migration mechanisms. Totally aside from updates to your app, you’ll often need to manage support for and deprecation of specific hardware and operating system combinations stretching back in time.
Testing, QA, and build automation are also different on mobile than in web development. Many teams have physical hardware in a device lab set aside just for manual testing. This is expensive and logistically challenging, especially as so many developers are now working remotely.
Release models in mobile development
Having a well-defined process is essential for any form of software release, but this is especially the case for mobile app development. Developers need to be able to coordinate with marketing, support, and leadership teams about when updates will go live, and because every change must be approved by app stores, communication and timing are key.
While every company is different, mobile development release processes generally fall into one of two major categories:
1. Release trains
Under the release train model, teams decide on a fixed schedule for cutting and shipping updates. When release day comes, only those new features and bug fixes that are production-ready will make it into the release; everything else has to wait for the next release train to go live.
This approach helps companies ship updates frequently and pushes developers to focus on smaller, more manageable pieces of work. Notably, it has been adopted by companies like SoundCloud and Facebook to improve their mobile release process.
To use this model effectively, developers need to keep other stakeholders apprised of their progress throughout each release cycle. Product managers and marketers need to know when specific features will go live so they can announce those changes in a timely manner. Similarly, other development teams might need to know about prerequisite features to prioritize their work.
From a user’s point of view, release trains can be reassuring. Users see regular updates with increased stability and more frequent improvements, giving them the impression that app development is active and ongoing. It may also mean that critical bug fixes and updates are likely to come more frequently, leading to fewer support requests and a better user experience.
2. Feature-based releases
With the feature-based approach, developers only release an update when a specific, pre-determined set of features is complete. While updates are often less frequent, developers can focus on getting an entire feature finished rather than worrying about hitting a specific deadline for the next release train.
The problem with this approach is that delays in any one part of the feature mean the whole release is delayed. Smaller, targeted hotfixes might be shipped between each feature-based release to help mitigate this, but this workaround can slow down the primary feature even further as teams must merge updates back into their work.
From a user perspective, feature-based releases can be good or bad. On one hand, users who opt out of automated updates might appreciate fewer upgrades, and more visibility into exactly what new features are landing with each update. On the other hand, fewer updates might make it look like your application isn’t being as actively improved, especially to skeptical users who pay close attention to the latest release dates in the app store.
Lowering mobile release friction
Having a coherent plan in place for your mobile releases is important. But in and of itself it doesn’t remove any of the hurdles required to ship updates. The team still needs to wrangle outstanding feature work, build binaries, test the app, upload binaries to the app stores, and add supporting screenshots, metadata, and release notes. As each update is installed by users, you also need to monitor logs, crash reports, and incoming feedback to make sure that nothing was missed in your QA process. Given these challenges, a deeper appreciation for the nuances of mobile release management can be the difference between a fraught release and a seamless one.
To illustrate all of these moving pieces, here’s a diagram outlining a typical mobile app release process:
As you can see, there are a lot of steps between writing the code and actually making the updated application available in app stores. Many of the steps are error-prone, time-consuming, and require close coordination between stakeholders across the team.
Fortunately, mobile app development is far from a new field now, and there are several best practices that can help you lower friction and ship with more confidence. Let’s look at a few of these.
1. Automated testing and continuous integration
Automated testing is important in all forms of software development, but implementing it for mobile apps is often much more involved. Testing across various device models and screen sizes is necessary, and many teams will also want to test under a range of different mobile network conditions. For many apps, especially those that leverage platform features like audio/video or location services, testing on actual, physical devices is called for as well. Modern mobile testing frameworks and services like Appium, Sauce Labs, and Mobot give you the ability to more easily manage and execute testing against emulated or real device hardware.
To automate the test runner and build process, app development teams typically use a mobile continuous integration (CI) platform like CircleCI, GitHub Actions, or Jenkins. These tools can also run linting checks, static code analysis, and any other task that can be triggered from the command line.
Most CI tools can be configured with customizable workflows, integrations with notification channels like Slack, and automated reporting. Not only does this help ensure that blockers like test or build failures are surfaced visibly and quickly, but it can help increase confidence through your entire release pipeline.
2. Release automation
The involvement of a third party (i.e. the Google Play or Apple App Store) means it’s not possible to automate the entire release and approval process, but modern tools can help you move in that direction. CI/CD platforms can prepare and sign binaries for release, AppCenter can manage beta and other testing deployments, and fastlane can be leveraged to generate change logs, capture screenshots, upload and submit your binaries, and more.
Most release automation is implemented via a continuous integration and delivery platform, but you can also run an automated release process locally to get started. To see how to get up and running with Apple App Store release automation using fastlane, check out this tutorial.
3. Clear communication channels
The bigger your development team and company, the larger the communication burden gets around releases. In a small startup, it’s relatively easy to ping back and forth over Slack to get everyone on the same page come release time, but in a large organization, you have to establish reliable and more deliberate communication channels.
As multiple teams become involved in every release, you need to figure out how team members will communicate with each other as they develop, test, review, and roll out the new release. Depending on your team’s workflow, there are some key transition points in the release process that need special attention.
- Engineers write code and perhaps run some tests locally. Changes are pushed to remote, possibly to a shared branch, and unit and automated tests are run on a CI server. The QA team then needs to know when the feature is ready for manual testing, and on which exact build.
- Quality assurance is performed manually to check for bugs on various devices. If there are issues, QA and product need a process for triaging them and handing blocking items back to the responsible developers. If and when there are no more blocking items, there has to be a process for sending the feature off for final verification.
- Other stakeholders like security and compliance departments make sure the app doesn’t violate any privacy standards, is compliant with security regulations, and adheres to the app stores’ policies. After their review, these stakeholders need a way to signal their approval to the engineers or product owners involved.
- As the release date approaches, engineering and product need to inform the marketing team so they can finalize user-facing release notes, approve screenshots, and optimize search keywords before the app is submitted.
- Shortly before or as the release ships, ops and customer service teams need to be looped in and informed of important changes that are arriving with this release.
Here, automation only goes so far, and teams need to work hard to establish very clear lines of communication and a strong understanding of roles and responsibilities across the team. Some documented procedures and dashboards can help set teams up for success in this area.
Takeaways
Mobile releases have come a long way in the past decade. There are now established models for planning and scheduling releases, tools for automated testing on various devices, and methods to automatically package and submit your application’s binary to app stores. Taking advantage of these modern tools will improve your app’s quality and make releases a lot less scary, but they don’t remove the need for solid communication and visibility within the mobile team and with other stakeholders beyond it.
