How teams plan and manage their mobile app releases can have a massive impact on their ability to ship stable, regular updates to users. A well-structured process can ensure predictability in release schedules, which makes it easier to align new features with business goals. It also reinforces user perception that an app is regularly and purposefully maintained.
On the other hand, a release process that is poorly conceived or unpredictable can lead to uncertainty and confusion among users, the mobile team itself, and other stakeholders. Disorganized releases also greatly increase overhead and wasted time across the development team.
You needed a release strategy yesterday
Having a defined process for releasing your mobile app helps your team ship features faster and with less friction. It ensures that product, engineering, and other stakeholders are all aligned — both within the mobile team itself and on adjacent teams (e.g. those responsible for backend services your app depends on). The benefits extend beyond just engineering and product: with reliable release practices in place, marketing teams are better able to coordinate announcements and PR, and customer experience teams can more reliably keep users informed of changes and address any bugs or feedback.
Releases that proceed smoothly and as-expected are also better for users. Users are likely more attentive to your app releases than you think, and they prefer using apps that roll out new features with timely updates. If you have big gaps between updates, it’s possible new or existing users will seek out an alternative app that is being more actively developed and improved.
Finally, at a higher level, having a coherent release strategy helps align your mobile development cycles with larger company initiatives. If executives can count on you hitting target release dates, or at least have a reliable way to follow along with releases as they play out, they can more easily track the outcome of improvements and plan subsequent initiatives based on those results.
Common release strategies for mobile apps
There are a variety of different approaches to organizing mobile releases, and no single one is “correct.” The particular approach and cadence that is most suitable for you can depend on your team size, company culture, the kind of product you’re building, and overall software maturity level.
However, mobile app development has been a thing for long enough that there are now plenty of sensible release strategies out there to adopt or draw from. Many of these have roots in traditional software publishing but have been adapted to the mobile app store distribution model.
In this post, we'll compare and contrast three common release strategies for mobile development:
- Feature-based releases
- Time-based releases
- Release trains
We’ll take a particularly close look at feature-based releases and release trains, which have become the most popular methods for mobile teams in recent years. By the end of this piece, you should have a good sense of which approach might work best for your team and app.
Feature-based releases: It’s ready when it’s ready
The feature-based release strategy allows teams to release new features as they are completed, regardless of the development time needed. A given release is planned around a specific feature or set of features, and the release is ready to ship only when the slated features become production-ready. If the features take one week to be built and verified, you will be rolling out your release in a week. If it takes three weeks, your release will ship in three weeks.
Feature-based is a relatively simple strategy, and is often adopted by agencies, freelancers, and smaller teams working towards specific, discrete deliverables. They may work with a client or stakeholder to define a set of features, implement those features, get approval from the third party, and then ship the whole thing in one self-contained release.
On the opposite end of the scale, feature-based releases are also common with larger and slower-moving engineering teams that ship updates relatively infrequently. These companies are often operating under more constraints and oversight, and sometimes they prefer not to deal with the potential risk and overhead of shipping incrementally.
Pros and cons
Following a feature-based release strategy, one developer (or a small team) working in isolation on a set of new features can easily build them out, get the all-clear from QA, and ship a release themselves. As long as there are no complicated interdependencies, and given a higher tolerance for releases to take just as long as they need, the feature-based approach can be appropriate and attractively straightforward.
However, if work involves more than one or two small teams, things can quickly become much more difficult to coordinate. For example, complications often arise when larger companies forego a single, centralized mobile team in favor of mobile resources spread across various product teams or functional “squads.” The fact that each team is building its own set of features, usually according to its own deadlines, but all contributing to the same eventual binary often makes the process of releasing an exercise in herding cats. Complicating interdependencies also exist between mobile and other teams: most notably, between mobile and the backend services and APIs it depends on. In these sorts of scenarios, a hiccup on the part of any one of the teams involved could delay the entire release and cause significant downstream effects as well.
Feature-based releases can also be hard to plan marketing and media campaigns around. If estimates are off (as they often are), product marketing teams may announce features too early, too late, or not at all.
For feature-based releases to be successful, especially in the more complicated use cases highlighted above, it’s absolutely necessary that the level of communication within and across teams be top-notch. There should be conscious communication plans and practices in place, with time budgeted for the necessary check-ins and syncs both within and between teams.
You can mitigate some of the risks inherent in feature-based releases by automating as much of the process as possible. CI/CD tools complement a feature-based strategy by allowing developers across teams to automatically test and integrate changes more continuously leading up to a release. This eliminates some of the common points of friction as developers and teams gradually contribute pieces of work into a feature-based release.
Time-based releases: Hitting deadlines
Under a time-based strategy, developers ship updates at specific points in time. The team must adhere to strict deadlines to ensure all features are complete and that releases can ship on schedule.
Pros and cons
The upside of this approach is that your entire organization can know with relative certainty when a release is going to happen. This makes it easier to coordinate and prep for releases with marketing, public relations, and customer support teams.
On the other hand, the time-based approach is less flexible and can lead to a more demanding and stressful process. It can be very hard to pause marketing and press efforts, so engineers might just have to work long hours or aggressively cut scope to meet the necessary deadlines.
Release trains: Leaving with or without you
The release train strategy is a specific type of time-based release whereby updates are made on a regular, repeating basis using a set release cadence.
The name derives from the analogy of a train arriving at a platform at a scheduled time. Only the passengers present on the platform at that time are able to board the train. The train doesn't wait for any passengers that miss the scheduled departure time; it proceeds to its destination regardless of who is ready. Eventually, the next train arrives, and whoever missed the first train can now board and be on their way!
Mobile release trains operate similarly: whatever work is present and ready for production at the designated cutoff time gets shipped, and any pending work must wait for a subsequent release.
‍
In setting up a release train, your team commits to a particular cadence (often weekly or biweekly) and to certain specific days of the week when key release milestones will occur: release “cut” (a.k.a “freeze” or “kickoff”), submission to the app stores, and release. Each cycle, given a backlog of work, your team will get through as much as possible before the release cut day. After this cutoff, no additional work can be added to the release, unless new bugs are found and fixes are deemed critical to the release. Final regression testing and build validation continues until the designated submit day. If all is well, you then submit your final build and — with Apple or Google’s blessing — release on the designated release day. (In practice, the release day is often somewhat fluid given that it can depend on factors outside the team’s control.)
In contrast to the feature-based strategy, the release train strategy focuses on shipping releases on a consistent schedule regardless of what features might be ready to go. This usually means feature work must be broken down into smaller pieces and either worked on in independent branches, or merged often but disabled using feature flags until ready.
Typically, a mobile release train includes three phases:
- Code cut/freeze - As features are developed independently, they are integrated into a common branch only when fully ready to ship (or hidden behind feature flags). At the designated time, the current state of code on that branch is frozen — either on the branch itself (by not accepting any further commits to the branch), or by cutting a separate release branch.
- Stabilization - Next, testing begins using a Release Candidate build generated from the frozen release code. Depending on the company, QA, engineers, PMs and other stakeholders might all be involved, running through certain test cases to look for any bugs or other issues. If deemed high priority, small fixes might be made during this phase of the release, but no significant changes are allowed. Worst case, the team might have to punt an egregiously problematic feature from the release. This can get a bit messy in practice, but if the team isn’t strict here, they risk derailing the train and delaying this and following releases.
- Release approval and rollout - After QA and other stakeholders sign off on the release, the final Release Candidate build is submitted to the app stores! This step is not unique to release trains—any mobile release must go through review and release—but it’s obviously essential to getting updates out to your users.
Pros and cons
With the release train approach, your team is able to release more regularly and without as much coordination overhead. Feature work doesn’t need as much synchronization between different contributing developers and teams, as is the case with feature-based releases. Releases become more predictable when there’s a fixed and recurring schedule, and this also indicates to users that you're constantly working to improve their experience and deliver more value.
The feature-based release approach has generally been overtaken in popularity by release train models, and there are a growing number of well-known companies adopting and executing successful release trains, like Soundcloud and Facebook.
But release trains can be tricky to implement well, and breakdowns in the process can land teams back in a state of uncertainty and confusion. It can be especially hard for product, customer service, ops and other stakeholders to know when specific changes and new features will actually land. Extensive use of feature flags compounds this problem. Teams that are transitioning from a feature-based strategy might find themselves struggling with this visibility angle the most.
Although they reduce some coordination overhead, release trains that operate at a high frequency can actually add to overhead in other ways. They put a strain on resources if automated test coverage is lacking or QA resources are limited, and they have a multiplying effect on the cost of various manual tasks and busywork required per release.
Can a hybrid approach work?
Teams often wonder whether they can get away with some sort of hybrid approach. Imagine, for example, instituting a release train that is often allowed to leave the station late when contributing teams or stakeholders want more work to be included. This can seem reasonable enough, especially if late departures are allowed on a case-by-case basis and are relatively infrequent.
The issue with hybrid approaches is that they water down the real advantages of a stricter release train, leaving your team in a less useful middle ground. As soon as your team entertains the idea that occasional delays are acceptable in order to squeeze in additional work, you lose the predictability and seamlessness you’d otherwise have with a true train. You open the door to extra friction and overhead as developers and stakeholders once again need to coordinate around what is actually making it into releases.
Conclusion
No single release strategy suits every mobile team. In deciding on a new approach to adopt or evolving an existing process, teams should evaluate their own specific needs and priorities, and identify those defining characteristics of their organization and product that would make a particular strategy more or less appropriate. Hopefully, with the context provided in this piece, you’re better equipped to understand your options and make an informed decision. Happy releasing!
