How to release mobile apps weekly

Challenges in the release of mobile apps

For backend and web frontend projects, releasing a new version can be fast and frequent if the scope is small and the iterations fast. In this way, feedback from users and the market can be obtained immediately.

By contrast, mobile projects are always more challenging.

First, a mobile app’s new version needs to be reviewed by the platform (App Store / Google Play), which means that it cannot reach users immediately after release.

Second, we have no control over the users’ willingness to upgrade. If we made the upgrade mandatory, it would severely compromise user experience, so that the new version generally can’t overwrite the old version.

A weekly release strategy

It is necessary to realize a uniform release plan when the project team is large in scale, especially when multiple feature teams are developing simultaneously. A release loop from the coming Friday to the next Wednesday is one of the practical strategy we’ve tried: it results in releasing new versions of iOS and Android apps every week.

Friday

Friday, as the start of the release loop, is mainly for completing the regression test of the new app version and submitting it for review. In this way, the weekend can be reserved for more internal testing and review by App Store / Google Play.

The team is responsible for executing the whole pipeline, publishing the beta package to TestFlight and Google Play beta channels automatically through the pipeline, collecting the regression test feedback from various feature teams, and finally, selecting the manual release mode to submit for review. 

Monday

In general, the review takes between one and two days. If there are no exceptions, approval is given by the following Monday. Before the official release, the team should check the data of the new version collected by the monitoring system. The product owner then determines whether to release it to end users depending on the test feedback of the previous Friday.

Several considerations should be kept in mind during this period:

• For the data validation of the new version, there should be a checklist (for instance, to validate whether there is a new version in the data collection system) to provide reference to the team and prevent omissions.
• The business side should set data validation indicators for the core business to evaluate whether to proceed to release according to feedback and data.
• Take the advantage of platform-support phased rollout. App Store and Google Play Store respectively provide different phased rollouts. For example, App Store supports seven-day gated launch strategy with progressive ratios.
• Where the new version fails the review or the product owner decides not to publish to users due to technical issues, the team should fix the issues and then submit it for review again. After passing the review, the phased rollout can continue.

Wednesday

The app crash rate is normally the key factor for a new release and is expected to be lower than a certain threshold. After the team confirms that it’s below that threshold, the new version can be fully released to reach all users.

After the full release, we should continue monitoring the crash rate. When the rate exceeds the threshold, a warning should be sent to the team and a hotfix released.

This brings the release loop to an end. Where issues are identified and the app is re-submitted for review, if the review is approved on or before Wednesday, the phased rollout continues without impact on the next release. If not, the hotfix can be merged to the next release loop.

With this strategy, even if one feature fails to catch the release train this week, the release interval is still controlled to remain within two weeks, meeting the requirement for a rapid and frequent speed to market. 

Practices behind the release strategy

Automation of release pipeline

The release pipeline is highly automated to improve release efficiency, avoid the burden of frequent release on the team and reduce possible mistakes in a manual release. One member of the team on duty is responsible for the release on iOS/Android every week.

The master branch and the release branch are adopted and enable the publisher to trigger the release pipeline with one click and upload the new version to App Store Connect and Google Play.

Quality assurance

We ensure code quality during development, and add multiple tests before the release to ensure the version quality, boosting release confidence.

• We have a testing pyramid to include unit tests, UI tests and e2e tests to cover test cases.
• Various tests are automatically integrated in the pipeline; the test coverage can be visualized.
• The team conducts a bug bash internally before the release of every new feature.
• Each feature is required to complete the regression test to match their business requirements.

Data support

For each business demand, there should be enough data support for the efficient decision-making of whether to publish to end users and the follow-up optimization of the business.

• The business side should set validation indicators for the core business.
• The app side should set event tracking during the development.
• The appropriate data tool platform should be employed to visualize data, facilitating analysis of the business data.

Risk control

Feature Toggle is a choice to control the development of new features while ensuring release flexibility and risk control.

• The feature under development can be released together with the app through the control of the switch, without hindrance to the current release pipeline.
• Reserve the feature toggle in the codebase until the feature becomes stable, ensuring we have the ability to rollback.

Continuous improvement

As for serious issues during the release, the team should immediately conduct PIR (post-incident reviews) after the release to analyze and find the root cause. Then, the team should formulate an action strategy and make continuous improvements for future development and releases.

Conclusion

The weekly release strategy can be run as flexibly as needed in both large multi-team projects and single-team projects. Besides the strategy itself, the practices behind ensuring app quality and team efficiency are even more important, which should be taken into consideration when designing the strategy.