Stress-free Mobile App Releases

Sep 23, 2022 · 4 min · Abhay Sood

Some thoughts on releasing mobile applications.

How it starts

How it ends

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… if there is a bug we have to again go through the review process on the App/Play stores, hence it’s good to be more thorough and spend that time testing the app”.

“because… we have too much workload, PMs keep asking us to release new features all the time, we have no time to write tests”.

“only if… we could do OTA updates without going through the app review process on App/Play stores”.

“only if… the team that worked on this codebase, before I joined, wrote tests”.

We also come up with cool sounding solutions

Road to stress-free releases

Apart from automated testing, there are other common areas which teams end up creating mundane work for themselves or create stressful situations:

  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.


2. If you don’t have a CI setup to build and test the app. Do it. There are lots of tools which make it really easy available today.

Automate releasing the app

Don’t hack release trains

  • 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

Also, do not invent a new branching strategy. A brilliant detailed post on branching for mobile apps on Tramline Blog

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

After some discussions, I realised that this article is not complete if we don’t talk about continuous delivery for Mobile apps.

One of the the key factors of being a high performing team is how fast you can deliver value to customers. On backend you can do this for every commit and deploy multiple times every day. However, there are some constraints for mobile apps to do the same:

  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.

A release strategy like the following is what I’ve found to work in some companies:

  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.

The confidence to be able to do this can only come from automated testing and a CI system which does these releases automatically.

Thanks for reading!



Software Engineer

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