This Version is not Supported - Upgrade now
We found a major security issue with our APIs and wanted to ensure that one API shuts down completely. But this was not easy; most of our app customers were on versions that relied on the buggy API. We decided to block all old versions of our app. The only option they were given was to upgrade to the latest app. The forced upgrade feature had saved the day for my team.
Let's say you are starting to write a mobile app that you hope will be used by millions of customers daily. What if I told you that for your first version, you must include a feature that you hope to never use? What if I told you that with every release's regression tests, you must test this 'never to be used' feature.
That's exactly what the forced upgrade feature is. A feature that should be present in every version (even MVP) of your product and you always hope never to use this it.
Forced upgrade (also called blocking, mandatory update) is basically a blocking screen informing customers that they must upgrade their app to experience the goodness of your services.
Why is it even needed?
If you are a mobile developer or a mobile product manager, I am assuming the question is only being asked to satisfy your curiosity. You probably already have force upgrades in your app.
If you are new to mobile development or are considering launching a mobile app; you must add this feature immediately and avoid pain in the future.
There are two things that make forced upgrade feature an essential one. App adoption cycle and software aging.
App adoption is slower than you think
I have known about app version adoption taking time for a few years and I have seen multiple forced upgrade exercises. I thought I understood the long-tail well but orchestrating this exercise a couple of times told me how absurdly long the long-tail really is.
When we release a new version of a mobile app, we can't assume that all our customers will upgrade to this new version and start using it. According to one survey, 35% of Android customers keep auto-updates turned off.
Another survey across 6000+ customers revealed that 45% customers don't auto-update apps.
If your primary market is India or other developing countries, the numbers would look even worse. Data charges are perceived to be high; not as many people use wi-fi. Android apps' new version adoption usually moves slower than iOS apps.
Based on my experience, here are some top-level estimates for how long it might take your new app versions to get to your customers.
NOTE: These numbers are representational only. Your app will experience different adoption based on popularity, customer segment.
After a version of your app has been released for more than a year, you will still see nearly 15% of customers using an old version.
Software ages and evolves
As it happens, your app and corresponding backend are changing continuously. Your APIs have different versions, you have new features, payment mechanisms, improved analytics, etc. Sometimes, you have a big security upgrade or your apps are now paid / free and you want all your customers to have a minimum version of your app. Old versions of apps have an end of life. A vendor may go under or make a breaking change; you may change a vendor and you don't want to pay your vendor based on a trickle of usage that will never stop.
Here is a non-exhaustive list of situations where forced upgrade comes handy:
- Cost of maintaining old API versions
- Security issues with APIs or API flows
- Vendor change/deprecation
- Feature / functionality deprecation
- Major design overhaul/rebranding
- New subscription options - app goes free / paid or adds tiers
- New features that are worth giving customers a blocking upgrade screen pain
App adoption and the need to ensure customers don't use an old version make forced upgrades a must-have feature.
Is everyone doing it?
You bet! Here are some screenshots from popular apps:
Some companies choose to keep a rolling 180 days or 365 days forced upgrades mechanism. This way the apps being used by their customers are never more than 6 months (or a year) old.
What's the right way to build and do forced upgrades?
The right way to do the forced upgrade is to NOT do it. But if you must, let's build it the right way first.
The feature must be available from your very first version, otherwise, you can't really get your customers to upgrade. You can break the first version by disabling APIs, but your customers wouldn't know why your app suddenly stopped working. You need to communicate how upgrading can get them up and running immediately.
You should be able to target specific versions and above in your upgrade messages. You don't want to block a customer who just upgraded to the latest app and ask them to upgrade again.
A link to the app store or in-app updates is a much better experience for your customers rather than just a prompt with 'okay' confirmation where customers are forced to open the app store on their own.
Keep the force upgrade mechanism simple. It's tempting to make it smart by addressing the type of customers, number of times the prompt is shown. Making the upgrade skippable first X times and then making it mandatory sounds like a great solution but breaks more frequently and requires more time during release regression testing.
Retain the ability to roll out a forced upgrade to a small segment of customers before making it mandatory for all of them. Paying customers complain when they are blocked, non-paying customers switch apps when they are blocked. Assess the damage to a business with a small roll-out first.
I have seen engineering teams using a upgrade.json (loaded synchronously or asynchronously on app start) to determine if they should so upgrade prompt. I have also seen remote configurations (e.g. Firebase, LaunchDarkly, etc.) being used to tell older versions of apps to show upgrade prompts. Some teams also use specific API responses to inform their apps to trigger a forced upgrade. This is how a simple implementation may look like:
- Go as far back in minimum version as possible, plan force upgrades for months. Minimize the number of customers who will see your upgrade messages.
- Use Google/Apple App Version statistics or your own analytics (include app version in your analytical events) to find how many customers are using older versions.
- Start with a soft upgrade prompt/in-app update if possible. Tell your customers what benefits they will get by updating.
Are there any alternatives?
GraphQL was famously the solution for handling breaking changes in APIs.
I still remember developing an instant liking for GraphQL when Facebook engineers claimed that some of their earliest app versions can still function thanks to GraphQL. Unfortunately, as I learned more; I decided GraphQL still doesn't eliminate force upgrades.
React Native code push is a similar attempt that gets rid of many reasons to do forced upgrades but doesn't eliminate the need completely.
I would love to see vendors like AppCues, LaunchDarkly, and others who are usually present on the first versions of apps to make the forced upgrade screens a bit better.
What's your forced upgrade story as a consumer and as a developer? Does your app already have an implementation and a policy?