Inactive/Failing Mobile Apps: The Many Benefits of Regular App Updates

This article applies mainly to mobile apps which are not in active development. It applies equally to mobile apps on the public app stores and also to enterprise mobile apps which get distributed via other means (such as MDM software).

Example scenario of an inactive/failing app:

• The active marketing of your app that happened at launch has now stopped
• Your app's last update was several months ago
• The uninstallation rate has started rising above your installation rate month on month

A way to prevent this happening is to release regular app updates, even when there are no major changes to your app's code.


Benefits of releasing regular app updates:

• Gain new users; many users look at the last release date on the app store page before downloading your app. Anything over a year old can be immediately rejected as out of date.
• Prevent uninstalls; seeing your app has been updated on their phone keeps it in the user's mindshare, so they know you are still actively developing it.
• Update the dependencies; you will likely have several dependencies on open source libraries and mobile SDKs. The more often you release, the more often these can be updated too.
• Update the toolchain; Xcode / Android Studio / Visual Studio get updated once every month or two. Same applies to hybrid and cross platform toolchains such as Unity, Ionic and Xamarin.
• Update the store listing; since you're doing a build, take the opportunity to review and tweak the store listing and screenshots. Apple's App Store Connect website and Android's Google Play Console get updated regularly with enhancements you can take advantage of.
• Less build issues; there will be a lower chance of a major build issue if you regularly update your toolchain and its dependencies. In my experience, the longer you wait between app builds and releases, the greater the chance of a major build issue the next time.
• Source control change visibility; the project is kept active in terms of source control history; especially relevant if its an open source project with other potential developers able to see the change history on github or bitbucket.
• Developer benefits; you don't end up with a legacy mobile app that noone can get building anymore.

What if there are no significant changes to your code?

• Have the dependencies or toolchain been updated? If yes, that means your app has gained some potential bug fixes and enhancements for free - just by doing a build.
• There's always some minor refactoring you can do to make small improvements to your codebase. Just spend a couple of hours if that's all you can spare.
• The release note; just use the standard "Bug fixes, performance and stability improvements" if you can't think of anything else.

How often to release?

• The more often the better.
• Aim for a regular release cycle of between 1-3 months.

Further reading

Distribution of Android apps per download range
https://www.statista.com/statistics/269884/android-app-downloads/

Download distribution of Android apps, and lifetime growth rates per download range
https://www.appbrain.com/stats/android-app-downloads

Statistics about the release schedule of apps on the Apple app store
https://stories.appbot.co/how-often-should-you-update-your-app-9405b85a967c

Best practices for Apple app store updates
https://developer.apple.com/app-store/app-updates/


Follow @dodgy_coder

Subscribe to posts via RSS