Stress-free Mobile App Releases

How it starts

“we don’t have time to write tests” or “writing tests will slow us down”.

How it ends

“we develop for 2 weeks, after which QAs do sanity testing for 2 to 4 days, then we slowly roll out to production in increments of 1%, 5%, 25%, 50%, 100%”.

Then comes the question. Why does it take 7–10 days to release 2 weeks of development work?

We then try to lamely escape responsibility

“because… we don’t have enough QAs to test the app”.

We also come up with cool sounding solutions

“let’s do server driven development (or use web views) so that we can fix some things on the fly”.

Road to stress-free releases

Ranjan Sakalley goes more into the topic of “Why is test automation the backbone of Continuous Delivery?” , it’s a beautiful article, must read.

  1. Uploading builds manually on Play/App store.
  2. Having a manual step to create a release branch & upgrading version numbers in code.
  3. Following a release train process, but allow for multiple commits after code-freeze without scrutiny.
  4. Having Long-running branches.
  5. Tying feature delivery with app release dates, creating unwanted pressure on engineers.

Automate testing

  1. If you don’t have experience writing tests, don’t delay it any further. A snippet from something I had shared with a team someone recently:
  • You do not need permission to write tests. Do it as part of your workflow.
  • It will feel slower in the beginning if you haven’t practiced writing tests.
  • Practice to get better & faster. Simplest way to start is to write tests for something simple like a calculator, part of a simple game like tic-tac-toe, snake, sudoku, game of life, etc. Then use that knowledge in the mobile framework you use for app development.

Automate releasing the app

Trigger a release from click of a button or by running a script. If there is any more ceremony around releasing the app which requires meeting, manual intervention, get rid of it over time. Automate everything, including version update, release branch creation, uploading builds to the store, uploading dSYM/source mapping files to crash reporting tools, etc.

Don’t hack release trains

Most teams today follow a release train process for releasing mobile apps. If your app release is mostly delayed from the set date for the release, you’re doing it wrong. Some pitfalls which you should avoid:

  • Do not tie publishing of an app version to feature delivery. This causes delays to app release if you find even one critical issue. Release trains work effectively if you have alternate ways to roll out or toggle features. This can be done easily for most cases with Firebase Remote Config.
  • Do not allow merges after code freeze. Remotely toggle off features which have critical bugs. For any critical bug raised after code freeze which delays the release train, have an RCA.

Don’t do long-running branches

Why are we still doing this?

Automation is the key for stress-free releases. If you have engineers working on releasing the app, and they do anything apart from automating the process or triggering a few scripts, I’m coming for you 🔫


  1. Automated or data informed rollout based on key metrics like crash rate, ANRs, performance, adoption, etc.
  2. Better testing frameworks, specially for instrumentation testing. Writing, running & maintaining instrumentation tests can be really expensive and time-consuming. Looking forward to what team is doing in this space.
  3. Faster feedback loop when writing tests. Build speeds generally come in the way. >10s incremental build time does not go well with testing. Flutter has pushed the bar very high on this .

Continuous Delivery For Apps

[Updated 28 Sept]

  1. App review process on App/Play stores can take anywhere between 1–7 days.
  2. Users have to spend their network bandwidth for updating the app. Which can get costly depending on your app size and data costs.
  1. Release to internal users daily. This will enforce keeping your app always ready to release and provide a faster feedback loop.
  2. Release to beta users (both app stores support this), daily or weekly.
  3. Release to production weekly or bi-weekly.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store