Don’t Live with Regret. Build a Kill Switch into your Mobile App
As a product manager, one of the unique challenges posed by native mobile applications is that you cannot unilaterally force users to update to the newest version of your app. Theoretically, a user could download and install your native mobile app at one point in time, and then never update the app again. Sure, most users have automatic app updates enabled at the iOS or Android system level, which means they will receive your newly issued app update within 24–48 hours of its publishing to the App Store or Play Store. However, a non-neglible number of users choose to disable automatic app updates, which means they can decide when to update, or not update, your app on their own terms.
As the months and years go by, you may dutifully add new features and deprecate old ones like a good product manager would. You may replace vendor capabilities, redesign and rebuild major product functions, and even swap out the API endpoints that power your mobile app. But, since you cannot force a user onto your new app version, you just have to live with those inevitable laggards who stubbornly refuse to upgrade. At best, users stuck in the past and running an outdated app version will experience your product as a hollow shell of its full potential. At worst, it only takes one measly little breaking API change and your old app versions can become completely broken and unusable.
That is… unless you have implemented a forced software update mechanism, also known as a kill switch.
A magic eraser
Conceptually, a kill switch is like a magical software eraser that can wipe away past versions of your app that are doomed to behave badly or disappoint users.
- Have you ever had to replace a critical vendor dependency in your app and needed a way to control the timing of the cut-over?
- Have you ever learned of a security vulnerability in your app and needed a mechanism to ensure the patch was deployed as soon as possible?
- Have you ever had to make the hard decision to sunset a feature and needed the ability to gracefully remove support for that feature?
- Have you ever changed your product name or brand image and needed to ensure the updated branding would coincide with a broader campaign?
All of these are great use cases for a kill switch to magically erase your mobile app’s past and force adoption of your most important product updates.
How does a kill switch work?
By definition, a kill switch requires a remote server component to be the “source of truth” for asserting a minimum recommended and mimimum required version of your mobile app. When your app is launched, it fetches the minimum recommended and minimum required version information from the server. Then, if the currently running app version is determined to be below one of the minimum thresholds, a prompt will be displayed indicating the app is due for an update.
It is a good idea to differentiate between minimum recommended and minimum required app versions, with the key difference being that a user can choose to defer upgrading from a version below the minimum recommended threshold. Conversely, a user cannot defer upgrading from a version below the minimum required threshold, meaning they effectively have to update the app in order to continue using it.
The example shown above depicts a “soft” kill switch prompt, where a user could choose to dismiss the prompt and update the app version later. In a minimum required scenario, the user would instead see a “hard” kill switch prompt with no dismissal button, thus forcing the app update.
If your mobile app consumes its own custom web services or APIs, it is nice to build a kill-switch mechanism right into your own API. See this article from Sam Kirchmeier for more about that and other nuggets of API design wisdom. However, if you aren’t able to build your own kill switch endpoint, there are many remote feature flagging tools out there that can accomplish the same thing. Firebase Remote Config is a solid option that is free of cost in many instances.
Practical tips for using a kill switch
While a kill switch can be a powerful tool for mobile product management, it should be handled with care and responsibility. After all, interrupting a user and forcing them to update their app version is heavy-handed and disruptive, even if occasionally necessary. If things are going well, you should only need to use your app’s kill switch sparingly. But because those repetitions are so scarce, here are a few practical tips for making best use of your kill switch on those sacred occasions when you really need it.
1. Have a kill switch
Many, many mobile product owners have regretted not having a kill switch, but not a single one has ever regretted having a kill switch. It’s effectively a cheap insurance policy against all of the inevitable change that comes with modern product management.
While implementing a kill switch is relatively straightforward in terms of development effort and complexity, it doesn’t come for free and should be prioritized accordingly.
Remember, a kill switch can’t help you retire old app versions that pre-date your kill switch implementation. Therefore, the only way to guarantee your ability to sunset or retire all app versions is to include a kill switch with the very first public release of your mobile app.
2. Pull your kill switch with confidence
Invoking a kill switch is a “no regrets” type of maneuver, so please make sure you are really confident in the version of your app that you are forcing users to adopt. Releasing a lemon of a software update is bad enough, but forcing all users to adopt that lemon is a surefire way to permanently lose user trust. You should be putting each app update through its paces by way of regression testing, but especially when you are forcing adoption of that update via your kill switch.
3. Pull your kill switch as quietly as possible
The user experience for a kill switch can be inconvenient, ill-timed, and even annoying. After all, you are blocking the user from doing what they presumably wanted to do when they launched your app. As such, do everything you can to minimize its impact.
If you have the luxury of a few days time, wait until your desired app version has reached approximately 80–90% adoption amongst your active users. As mentioned earlier, most consumers today are set up to receive automatic app updates on their mobile device. This means within 24–48 hours of public release, the mobile operating systems will update your app version on your behalf for 80–90% of active users with no intervention needed. Use this to your advantage and take that 80–90% for free, then focus your kill switch on the long tail — those 10–20% of users that don’t have automatic app updates and need an extra nudge.
Do your future self a favor
So much of modern digital product management is embracing change and coping with future uncertainty. Having a kill switch is a tangible acknowledgement that we may not have all of the answers for our product today, but we are humble enough to know we’ll need the flexibility to change our mind about how it works in the future. It may not seem immediately obvious, but someday, you’ll be glad you took the time to build a kill switch into your mobile app.
Matt manages digital products without regret at Livefront.
