What you need to know about app update roll-outs

How long does it take for your app update to reach users after you've released it in the app stores?
Distribution, How To
Gabrielle Earnshaw author image
Gabrielle Earnshaw
Article header

When you release an updated version of your app on the app stores for iOS and Android, it's easy to think your app is live with all your users, as it would be for a web app.

But for mobile, that's not the case. In fact your app is only just beginning its distribution journey. It will take time for your new version to arrive on users' devices. In some cases it will never arrive at all!

Let's take a look at how apps versions distribute, and what that means for your app releases.


How app version updates distribute through the user base

The chart shows data for a real app. Each colour represents a different version, with the iOS and Android versions grouped together. The vertical shows the number of users on each version, so the more space a version takes vertically, the more people are using it. When a new version is released, you'll see it expands out across the user base until it becomes the dominant version. It continues until another new version is released, and the whole process starts again. Let's look more closely at the detail.

Chart showing the time it takes for an app update to reach users after it's released in the app stores
  1. Version A starts as the dominant version.
  2. Version B is released. Over a few days, it grows to become the dominant version. The same happens with versions C and E.
  3. When the version is made available to all users, it takes 4-5 days to ripple out to most of your user base.
  4. There's a long tail of users who stay on version A, even after version B has been released. Some will update eventually, but some will stay on version A forever, meaning you end up with a 'sediment layer' of old app versions. This particular app has approximately 100-200 different versions used in the last month alone.
  5. Version D didn't distribute much before version E was released. This was because the team found a bug. Even though the fix was released quickly, version D still made it out to almost a third of users, and will live on in the sediment layer indefinitely.
  6. For this app, each new version has a small 'lead-in' time where the app is going out to a small subset of users so it can be validated before it is fully released. You can do this by using beta test groups or phased roll-outs, but it doesn't happen by default.

What does it mean for your app releases?

1. App releases aren't instantaneous

It's easy to think that an app update will be on a user's device straight after it is released, especially if you're used to dealing with web apps. In fact it takes around 4-5 days for it to get to the majority of users, longer for some, with others never getting it.

You need to be prepared that bug fixes and new features won't arrive instantaneously. APIs and other integrations relied on by your app need to be backwards compatible, as old versions continue to hit them.

2. Apps automatically update within a few days for most users

Although some users never get the update, the majority will within 4-5 days. If you're tempted to use a force-update mechanism to force users onto your new version straight away, you probably don't need to. It's rarely necessary, and should be avoided - some users will delete the app, when they would have got it soon enough anyway.

3. New downloads will always be the latest version

Once the app has been released, new downloads will always be the latest version. This applies to first-time downloads, users deleting and re-downloading, and downloading on a new device. It also applies even if you're using the store's built-in phased roll-out facility. If users have a device that doesn't support the latest version, they won't be able to download it, even if they previously had an older version installed.

4. Some users never get an app update

While the majority of users get the update, some never will. Every app version will end up in the 'sediment layer' (see the graphic in the first section). For example, approximately 100-200 different versions of this app were used in a 30 day period.

This happens for a few reasons, including:

  • They have automatic updates switched off, and not get round to updating manually.
  • They choose not to update in case you change or remove features they rely on.
  • They can't update because they have an old version of iOS or Android that doesn't support your latest update.

You need to consider how long APIs and other integrations relied on by your app need to be backwards compatible to support these older app versions.

Read more about how to decommission an API used by older versions of your app

5. Bugs and broken versions can live forever

Because app releases aren't instantaneous and some users will never update, bugs and broken versions can spread across your user base and stay in use forever. High impact bugs can do serious damage, so you have to invest more in testing than you might for a web app. To mitigate risk there are other techniques such as beta testing, phased roll-outs and remote config kill-switches that you can use.


Commonly asked questions

Here are answers to questions I am commonly asked about app version updates and releases. If you have another question, get in touch via Ask Me Anything.

Can I slow down the roll out?

Yes, but only if you set it up before the release. The iOS App Store and Google Play Store have phased roll-out facilities, that gradually ramp up the number of users receiving updates, starting at 1% and doubling each day. You can pause a phased roll-out so it sits with only the users who already have it (and new downloads). If you're not using a phased roll-out there's no way to slow it down.

Read more about how to use phased roll-outs for iOS apps

Can I speed up the roll out?

No, it will ripple out in its own time. However you can speed up a phased roll-out by ending it early.

Can I release changes to users instantly?

Not by releasing a new app version, but there are more advanced techniques you can use.

You can implement feature flags to make a feature available to all users at the same time. Note that people on versions without the feature still won't get it.

There are some services such as Code Push, Expo Update, and Shorebird that can remotely push code to apps without needing a store release. You can use these in some circumstances.

Can I force all users to be on the latest version?

Yes, you can implement a force-update mechanism. This won't push an update to users, but it will force them to update the app to keep using it, which prevents anyone using older versions of your app. Keep in mind that some users will stop using your app, so this should be used as a last resort. There is a built-in way to do this for Android, but you'd need to roll your own or use a third-party service for iOS.

Can I roll back a version if there's a problem with it?

No, there is no way to roll back a version on the stores. There is also no way to slow down the release of a version unless you are running a phased roll-out. Your only option is to fix-forward with a new version.

Need help with this?

Feel free to ask me anything

Other articles you might be interested in:

How To

How long does mobile take?

From features to fixes: how long it takes to develop mobile apps.

Gabrielle Earnshaw author image
Gabrielle Earnshaw
Distribution, How To

Mobile CI/CD: Are you set up for delivery success?

Improve your mobile app delivery with the right CI/CD approach

Gabrielle Earnshaw author image
Gabrielle Earnshaw

If you found this article useful, why not subscribe to my newsletter?