5 golden rules of app updates
The coming of the App Store (and other similar, non-capitalized app stores) means you can update your app indefinitely, adding features, responding to customer requests, changing the app until it eventually becomes a different beast altogether.
However, as with most things in life, just because you can, doesn’t mean you should. Here are my 5 golden rules for putting out app updates, designed to keep your customers happy, your sales high, and your sanity in check.
1. A buggy update is far, far worse than no update
If you’re only going to follow one rule, make it this one. Spend the extra time and make sure your update is fully tested on all platforms.
I was bitten by this with version 1.50 of WordCrasher on iOS, which showed graphical glitches for upgrades who were in the middle of a suspended game when updating (see above image). The result was several hectic days of scrambling to produce a patch, answering support requests and minimising damage to the WordCrasher brand.
2. Only add, never remove functionality
Removing existing functionality from one point release to another is a guaranteed way to receiving some damaging 1 star reviews on the App Store. The customer perception is, quite rightly, that they paid for functionality which you have subsequently removed.
I’m surprised we haven’t seen more litigation based on this.
3. With that in mind, be mindful of changing functionality
Changing functionality can be similar in damaging effect to removing functionality altogether. With games, changing a control scheme, even for the better, will alienate players who were used to the old way. And these players will not hesitate to give you a 1 star review.
The solution? Add an new alternative control scheme rather than changing the existing one. Make the controls default to the new scheme for new players, but keep the same scheme for old players, with the option of switching over.
The best solution? Get it right in the first place. The first release of an app is the most important release, as it sets out the expectations for future updates. It’s very hard to remove or change functionality after launch without invoking customer backlash. And since most reviews are based on the first version, there is extra incentive to get it right first time.
4. Consider your update granularity carefully
Unless you’re using regular updates as PR in a similar way to Doodle God, don’t update too often. Until the process is improved, updating apps is a chore for the end user. At the time of writing, I’m seeing a little red badge with the magical number “68” hovering above my App Store icon. I’m not sure I’ll ever catch up. And for the developer, more updates means more chance of buggy updates.
Of course, a good update now and then can reinvigorate interest in your app. If the updates are substantial enough, you may even be able to get some publicity out of the update. Releasing the same functionality in drips is much less likely to be newsworthy.
5. Think twice before removing support for a legacy OS version
As we move on through successive versions of both iOS and Android, it is inevitable that older devices get left behind. As you update your app, it may be tempting to remove support for older versions of the OS to clean up your code, or leverage new functionality exposed in later OS versions. However, bear in mind that doing so will cut off customers with older devices from subsequent updates. Worse still, if the customer is on (for example) iOS, and has multiple devices spanning multiple OS versions, iTunes may well update their app to the latest version, which is then incompatible with their older devices. Something that they will find, to their horror, the next time they sync with iTunes.
