Flock.ing @ bol.com - Mobile App Updates

This post is part 2 of a mini-series about Flock.’s involvement with the mobile app development at bol.com. Check-out the first post here

Biweekly Android and iOS app updates at bol.com introduce new features, remove the obsolete ones, add or remove a/b test code and eliminate bugs. In a perfect world, all users would update their apps automatically overnight, the customers wouldn’t miss out on new features and bol.com wouldn’t need to monitor, maintain and support old versions of the app at all, as is common practice with web applications. In reality, however, there are still some users who do this manually or – worse even – don’t do it at all. Without a clear strategy on the last part of the app’s lifecycle – the decommission phase – every month 4 additional app versions would be added to the “almost-obsolete-but-not-quite-yet” bin. And these need to be supported, possibly forever.

As it’s bol.com’s ambition to guarantee the best possible user experience for all customers, we needed to ensure that this was also true for the app users who happen not to (actively) update their app. Besides that, we wanted to improve the developer experience by reducing the amount of app versions ‘in the wild’, therefore reducing operational costs and greatly simplifying backward compatibility complexity. This, in turn, allowed for timely removal of deprecated APIs used by the app as well as migrations to newer frameworks.

Naturally, this task didn’t come without challenges. There were many stakeholders involved: the app teams, the teams responsible for the data of a (to be deprecated) feature, as well as customer support, marketing and legal departments. But the most important challenge was: how do you ensure great user experience for those who need to update?

We started off by encouraging business analysts, product owners and other stakeholders to come up with metrics on how to decide when to ‘force’ users to update their app, essentially by discarding their current installed version altogether. It was a trade off between usage, potential user loss, update frequency, developer experience and other criteria. Secondly, we introduced a distinction between ‘update’ and ‘exit’ flows, where the exit flow tells users the app cannot be used on their devices’ OS anymore (e.g. iOS 9 or Android 4).

Thirdly, we resigned the whole UX for the update flow, which we’ll see later on. Lastly, we also designed an API endpoint that tells the caller whether to update or not, based on OS and app version. This would serve as a replacement of a piece of remote configuration, allowing far more flexibility on determining which app version / OS combinations need to be updated. 

As a result, the mobile app creates awareness among users that work with an outdated version. No clunky, annoying modals or overlays that pop-up when you open the app, yet something prominent enough not to miss while using the app. This solution is called the soft update/exit and is placed on the home screen, right below the top banner..

One more aspect worth mentioning is the grace period which is available whenever the soft update is activated for a certain version. It offers an incentive for users to update, which leads to a greater adoption of newer versions of the app when activated, yet still allowing the customers to use the app as usual. A similar banner is shown for the exit flow, warning the users that their device is about to be unsupported, which means they soon won’t be able to use or update the app anymore. 

After the grace period has ended, only a single screen will be available when opening the app, telling the user their app version has expired and needs to be updated. In some cases a user will not be able to update the app and is presented with the exit screen. However, this will only happen when the app is installed on a device with an OS that is no longer supported by the bol.com app (due to OS being unsupported by the manufacturer or hardly used anymore). 

Overall, the app update project has led to a more consistent experience for all app users, and less feature inconsistency over its supported versions. It is expected to reduce the number of customer complaints as well as the workload for the developers. The decommission part of the app version’s lifecycle is properly taken care of and the APIs needed by the mobile app can be deprecated in a timely manner now.

This concludes the second part of the mini-series on my role at bol.com for the past 2 years. Curious for more? Keep an eye out for part 3: Project highlight #2: the multilingual app

Disclaimer: some of the actions described here were still in progress when I left. The results described however are based on factual information.

Cover photo credit: Left image by William Hook on Unsplash, middle image screenshot from google play store. Right image by Mohamed Hassan from Pixabay