The Long Tail of Old App Versions
Old versions of the app will stay around for a long time - this can be measured in years. This is unless you’re one of the few teams that have a strict force app upgrade policy in place. Apps that have a rolling window of force upgrades include Whatsapp and Messenger. Several others use force upgrades frequently like banking apps Monzo or American Express.
While the majority of users will update to new app versions in a matter of days, there will be a long tail of users being on several versions behind. Some users disable automatic updates on purpose. However, many users cannot upgrade because of old phones or OSes. - some doing so on purpose. At the same time, old app versions are unlikely to be regularly tested by the mobile team: it’s a lot of effort to do so, with little payoff.
Even a non-breaking backend change can break an older version of the app - such as changing the content of a specific response. A few practices to avoid this from happening:
- Build sturdy network response handling and parsing, using dedicated tooling that solves for these problems. Prefer strongly typed, generated contracts between client and backend like Thrift, GraphQL or similar solutions over REST interfaces with manual validation - which is bound to get out of sync.
- Plan well in advance for breaking backend changes. This means having an open communications channel with the backend team, having ways to test old app versions, and often having the tough conversation of building new endpoints, and not retiring old ones, until a force upgrade feature is in place for the majority of users.
- Version your backend endpoints and create new versions to accommodate breaking changes. Note that in case of using GraphQL, GraphQL has a strong stance against versioning. When making breaking changes, you’d usually create a new endpoint and mark the existing one as deprecated.
- Take care when deprecating endpoints on the backend: monitor the traffic, and have a migration plan on how to channel requests, if needed.
- Track usage stats on an app version level. What percentage of users is lagging 3 or more versions behind? Once you have this data, it’s easier to decide how much effort to dedicate towards ensuring the experience works well on older versions.
- Put client-side monitoring and alerting in place. These alerts might be channeled to a dedicated mobile oncall, or just the normal oncall. We’ll dive into monitoring and alerting in more detail in Part 3.
- Consider doing upgrade testing, at least for major updates. Upgrade testing is expensive, hard to automate and there might be several permutations to try. It’s rarely done by teams because of this overhead.
You are reading an early draft from the book Building Mobile Apps at Scale. For the final, expanded and improved content, grab the book now - it's free to download as a PDF until 31 May.
Building Mobile Apps at Scale
"An essential read for anyone working with mobile apps. Not just for mobile engineers - but also on the backend or web teams. The book is full of insights coming from someone who has done engineering at scale."
- Ruj Sabya, formerly Sr Engineering Manager @ Flipkart