Maintaining Your Mobile App is an Exercise in Forward-Thinking
A mobile app is ever-changing.
Regular updates are an essential task to ensure your app stays compatible with the digital ecosystem, and to meet your end-users’ evolving needs. So how do you hang onto your sanity, as well as your development and testing dollars, when you need to make changes to the back end (server-side) that communicates with your app? And what happens if you want to migrate your app from one vendor to another, or to your own team? The approaches discussed below are just a few examples of how to deal with the more complex aspects of updating or transitioning your app.
The versioning challenge
Publishing each new version comes with a unique set of challenges. Most users set their apps to auto-update. However, our analytics show that just under 20% of customers, both iOS and Android, don’t use the auto-update service, and that’s a big chunk of audience you don’t want to alienate. Their resistance to update an app could be for a variety of reasons:
- Some users have old phones and don’t have an auto-update feature
- Some have limited access to wifi and don’t want to update over mobile data
- Some may be hesitant after a bad update experience in the past
- And some just don’t care about having the latest version.
To cater to this laggard audience, most app developers build backwards compatibility into their apps, which is often not an issue if your APIs remain the same over multiple iterations. But when you do change the API, backward compatibility becomes challenging since you have to support both the old and new APIs. Over time this can become very costly and tedious.
In an ideal scenario, your app should have the built-in ability (called a web service) to track your customer’s app and API version and alert them when an update is available. For example, each time your app starts, it should perform one of three actions:
- If the version is the latest, do nothing
- If the version is older and still supported, allow them to continue using their version and alert them of the new version
- If the version is very old and no longer supported, alert the user they need the latest version in order to continue using the app.
While action #3 should only be used sparingly since it doesn’t give customers a choice, this tactic can save you money in the long run because you won’t have to build in endless backwards compatibility. You also save significant testing time, effort, and cost. And it keeps your app’s API structure streamlined and clean.
Transitioning apps to new developers
A version notification feature is also immensely useful when migrating from an old app developer to a new one. For example, when your new app is ready, simply ask the old developer to publish a message through the old app’s alert feature (web service) to alert users of the new version. This helps ensure your users migrate to your new app in a timely manner.
But if your old app doesn’t have built-in alerts, the situation gets tricky and you may find yourself in one of three possible scenarios:
Update and communicate
If your old vendor has the capability to build the alert functionality into your old app, and you’re willing to pay for it, you can use it to notify your customers about the new app. The disadvantage, besides paying the old developer for temporary work, is that they must release a new update to the app store, which means users will need to update, and then update again almost immediately to get the new app. Be sure to have a conversation with your old vendor as early as possible so everything is ready in time for the new app release. This solution gives you control over when to turn on the alert for the newly-upgraded app.
Communicate only
Perhaps you don’t want to pay your old vendor to make updates to your old app, or maybe the old vendor can’t make the updates in time for your new release. In this case, ask the old vendor to implement a forced migration alert that directs all users to the new app. A drawback of this scenario is that you don’t have control over when to turn on the update alert.
Vendor roadblocks
If your relationship with your old vendor has broken down, you have no other choice but to ramp up your marketing efforts. Create an extended campaign through your website, social channels, and email newsletters to notify your users about the upcoming new and improved app. Also, alert your customer service team about the required app update since they will soon be fielding support requests from users saying their old app isn’t working properly.
You may also be able to get around the vendor roadblock if you control the content displayed on certain pages of the old app, e.g. product pages. If so, add a message to those pages to direct users to the new app version. It’s not as efficient as your digital marketing efforts will be, and it can be a pretty ugly user experience, so it should only be considered as a last resort.
Avoiding failure to launch
When launching your new app, remember to test the upgrade path. Many companies overlook this when linking the old app to the new release. A faulty upgrade path creates a broken experience for your users, which is exactly what you want to avoid.
An important choice, a valuable relationship
Upgrading your apps is a necessary exercise and minor version updates can often be done without any challenges. But every so often, an in-depth upgrade may require consideration from a number of different angles. That’s when having the right app developer makes all the difference, not only to your final product but also to the process of getting there.
Choose a vendor that can see all scenarios, that can provide multiple solution options, and that has the skills to build the necessary functionality to transition your app smoothly from old to new. And ultimately, choose a vendor you can trust.
As a digital product shop that builds smart apps powered by machine learning and crafted using fact-based, user-centred design, we can show you the way. Reach out to us at hello@applydigital.co
