So, you’ve brought a beautiful app to a marketplace filled with eager fans and you’re seeing steady returns from the app monetization strategy you built behind it.
Now only a faint smell of champagne still lingers over your conference room.
But this isn’t the time to rest on your laurels. The fun is just getting started.
Now it’s time to decide when your prized product is due for an update.
Who Are You And What Do You Want?
No one can truly tell you when or how often you should be updating your app. After all, no two companies and no two apps are the same. But here we are going to try our best anyway.
The first factor to consider is the role of the app within your business. If the app is simply a supplement to your core services, then that does alleviate some of the pressure to push out frequent updates. However, if the mobile experience is at the heart of your business model — as with, say, a music streaming service — then you’ll need to move more aggressively. A quick look at the App Store shows that the music streaming service Spotify rolled out 24 versions for its iOS in 2015, and the team has already managed to squeeze in an update in 2016. (That’s no small thing considering how tricky it can be to navigate Apple’s approval process.)
Your choice of app platform will also likely affect the pace of your release schedule. With Google Play, developers can submit new updates immediately, whereas with Apple (and Amazon and Microsoft) each new update is treated as an initial release subject to a full approval process. Apple will speed up the process in the case of serious bugs or security fixes, but this is reserved for extremely dire situations. Unsurprisingly, Android developers update nearly twice as often as iOS developers as a result. Another variable to consider is whether your team is working in iterations with an agile development structure. If so, then the idea of delivering continuous, incremental updates should already be second nature to you. Your initial release was likely a bare-bones MVP, and you have kept an ever-watchful eye on changes to requirements so you may adapt accordingly and ensure that your product remains relevant. Nimble as a ninja, you patch up what needs fixing and spruce up your app with added functionality and new content with such regularity it would bring a tear to Ken Schwaber’s eye. In that case, your sprint schedule should already tell you when you will be releasing your next update.
But what if you are not an agile acolyte? And even if you are, what other factors should be on your radar?
Changes to Hardware or Software Platforms
Arguably, hardware and software changes are the most important (and most obvious) catalyst for updates. An app will behave differently depending on the device, even while running the same OS version and identical hardware components.
One major hardware wrinkle that could trigger a change in your app’s behavior would be modifications to the screen size of the target device. Alternatively, when the iPhone 4 launched with a Retina display it doubled the number of physical pixels both horizontally and vertically. This required web and mobile developers to drastically improve the resolution of their graphics as well. Countless smaller issues like changes to the camera, chipset, RAM, battery life and sensors may also end up affecting how your app behaves. Not all of these hardware changes will translate to immediately perceptible problems (i.e. “I tried it out on my phone and it displays fine.”), but as in the case of higher screen resolution, they may provide a push to elevate your app experience and get out ahead of evolving user expectations.
With regard to software updates, the key issue for most developers will be changes to the device’s operating system. OS issues rarely happen in isolation, however, and are most often seen in tandem with updates made by the device manufacturer.
Platform issues are more likely to come up with Android OS. Because, lacking the beautiful hive mind of Apple users, Android users remain loyal to a wide range of available Android versions. Therefore, developers are forced to test for editions as far back as Android 2.3.3 (Gingerbread) and make their way up the chain to 6.0.1 (Marshmallow). With each deliciously-named Android version comes the danger of drastically altering the way your mobile application behaves and redefining which third-party APIs you are able to use.
If your app relies on the functionality of another app, other updates may be required. In some cases you may be looking at something as clear cut as an extension or a plugin, in other cases it may be a question of social media integration. Updates to those apps may affect yours and need to be monitored.
Finally, there’s the case of changing design fashions. Design trends are a fickle mistress, but ignore them at your own peril when Apple or Google issue new guidelines. There’s no escaping the fact that you will need to adapt eventually. We saw clear cases when Google introduced its 2014 Material Design for Android devices and when Apple embraced Flat Design for iOS7.
Bug Grooming
You may have poured enough sweat, blood, and tears into your app to make it a health hazard and tested it to within an inch of its tiny app life, but there’s no escaping security patches and bug fixes. As your app scales, expect some unforeseen issues and make regular bug grooming part of your hygiene routine.
A good way to stay on top of your bugs is to keep a clear line of communication with your users. With frequent and detailed feedback you are better equipped to respond to urgent issues effectively. Dedicated in-app messaging features could pay significant dividends in this regard.
Go With the Flow
With all software and hardware up-to-date, and your new app carefully culled of pesky bugs, you may be nearly ready to rest on those well-deserved laurels when your competitor suddenly introduces a brand-new feature threatening to become the new industry standard. While it’s not recommended to become overly anxious about keeping pace with every update introduced by your competitors, you will need to stay ahead of features which permanently raise the bar and adapt accordingly.
Comments