Consider the following situation. You have had an App in the App Store for a few years and it is used by quite some people. At some point you decide to rebuild the app or refactor it in a significant way. You rebuild the app, test it thoroughly and release it to your (undoubtedly super-happy) userbase.
On the first day of your release, your enormous userbase finds a terrible bug. The backlash is terrible and any credit you had with your users goes out the window.
The first part of this story is where we found ourselves 2 years ago. We were not afraid to update our app in a significant way but we were aware of the dangers of rebuilding an entire app from scratch and putting it in the hands of hundreds of thousands of users from day 1. We decided to come up with a more low-risk tactic for the development and release of our apps. Here’s how we did it (until now):
While developing the app, we tried to get the app in the hands of as many people as possible, but only people we knew could handle an unstable and ever-changing product. This first alpha group consisted mostly of colleagues and family members. This was our first line of defence for any huge bugs we potentially introduced in our product. Our Apps were distributed via TestFlight and the Google Play store but were not publicly available. We tried to release as often as possible to keep our test users engaged and up-to-date on our progress.
Next, we recruited a beta group of of about 200-300 real users who were excited to test our unfinished product and give feedback. This feedback was given through an in-app feedback form (powered by ZenDesk) as well as through several to-the-point questionnaires we sent via email. We added screens to our apps that made it clear which functionality should be considered “finished” and which functionality was not available yet. This was done to further manage the test user’s expectations.
When we felt comfortable with the stability of our apps and the most basic functionality was implemented, we took the plunge and put our app in the App Store. However! We took a slightly different route than companies normally take. We decided to put our new fancy App in the store as a second app. The original app, with a lot of users, remained in the store. Our intent was to let the userbase of our new app gradually migrate to this new app and not “scare” them with an app that was not only radically different, but also not feature-complete yet. We originally called this app “<appname> beta” but when we tried to update this app (not on the original submit unfortunately 😉 we were notified by Apple that this naming was not allowed. We opted to go for “<appname> vernieuwt (renewed)”. We made sure to properly communicate in the App Store as well as in the App itself that this App was in a state of flux and that it could still contain some bugs. Also we encourage users to give us feedback or to report any problems in the app.
Migration our users in our “old” apps to the new apps was not going to be easy. Even though the original “organic” traffic to the new app was pretty steady we still wanted to encourage existing users to use our new product. We did (and still do) this by showing banners in our old apps. Because we know exactly which functionality people use in our apps through analytics we are able to target these banners only to people who do not use any functionality that is not available in the new app yet. As we add features to the new app and the two apps are more in-sync, we can target more and more users via these banners.
This is where we are now.
Since we already have our new app in the store and more and more people are using it. The actual action of “releasing” changes slightly. Instead we focus on migration of users to the new app until we reach a point where we can safely “turn off” our old app and remove it from the store.
Sure, it’s nice to push a big red button and launch a new version of your app. But considering the risks of updating an app with a huge userbase, isn’t it also nice to slowly introduce these people to your new product and not scare them off?
Currently we cannot determine yet if this tactic will pay off and if it does result in a more stable, robust and user-friendly app. I will keep you updated on our progress. In the mean time, why not consider your own low-risk release tactics?