Release of the first version of a mobile app is an important milestone in the evolution of a software product—yet it’s not the end, it’s just a milestone. People start to download the application and use it, rate it and leave feedbacks. But what happens after the first release? What comes next for the product owner?
Updates
This is the answer. Updates are an integral, continuous part of evolution. They maintain long-term quality and relevance of the product for end users.
Why are updates vital? There are 3 major reasons:
- All the technical debt that has been gathered while developing the Version 1.0.
- List of new features that have to be added: either those planned by the product owner, or suggested by user feedback, or new features dictated by changing environments.
- Involvement of new users and retention of existing ones. It’s important to satisfy their expectations in the world of constantly updated devices and OS versions, and emerging competitors. The most popular iOS and Android apps have the highest number of competitors on App Store and Google Play respectively.
So how are these updates put to good practice? Let’s see the main aspects.
Eliminate Technical Debt
Let’s start with technical debt and fixing of existing bugs in particular. These can be some low-priority minor issues that are already waiting in the bug-tracking system, but were deliberately left out of priority for the sake of timely delivery, or some new bugs that have been found by users and reported to the technical support team. Fixing them may, or even will bring new issues.
That’s the sad reality of the ever-changing software development world. There is no bug-free software, and that’s an axiom. But every app is already living, and there are real users that are using it right now. So the cost of a bug that has slipped into production is even higher at the moment. What’s more, the product owner will have to wait until the app update is approved and published by the chosen distribution platform, which means users facing these bugs some more time.
But there is nothing that cannot be fixed by a professional QA team. What’s more, if it happens that a critical bug is found immediately after the release, it is still possible to fix it by requesting an expedited app review. The main thing is not to abuse it.
Devices For Testing
The next thing to speak about are devices for testing. There are so many different devices on market with such a high fragmentation of technical specs, so it is obviously impossible to test the app on each and every one of them.
The initial list of devices approved for testing the first version, which was based on global statistics, common sense and intuition, is already outdated by the time the development is completed and the product is released.
The average development period of 6 months is a really long time for the mobile world. There already have appeared:
- new devices
- new OS versions
- new devices with new OS versions
- new devices with old OS versions
- old devices that were lucky to get an OS update
- but not all old devices are that lucky…
- …and not all users update their devices
Such is the real world, where users can have the same device model with 2 or more different operating systems on them—and each with its own issues.
So in order to succeed, it’s necessary to use analytics and update the list of supported devices quite often, keeping an eye on the app statistics and device preferences of real users. As the load on the QA team increases with new supported devices, it’s useful to consider remote device farms and test automation.
Adding New Features
New features are mainly associated with new functionality or 3rd-party integrations (e.g. Facebook, Dropbox). They bring new issues, so testing remains important. It is a safe practice to roll a new update not to 100% users at once, but rather to 10% instead. If there are issues, they will be reported, and the fixed updated may be rolled out to 20% users. This staged rollout will allow to cover all users with a good update.
There are new hardware features as well. Device manufactures are continuously developing something new, be it curved screens, 3D Touch, or smart wearables like Apple Watch.
There is a good example. Less than 3 years ago there were no fingerprint sensors in devices, but nowadays an app is not trendy if it doesn’t support Touch ID. Google developed its own native API for fingerprint authentication only in Android 6. Meanwhile, Samsung has been supporting devices with fingerprint scanners with its own API since Android 5. So a new app with fingerprint authentication for Android must support at least two different APIs with different issues.
What’s more, emulators do not provide real user experience, therefore do not guarantee that the app will run exactly as expected; that’s why QA engineers always emphasize the necessity of testing on real devices.
Conclusion
Updates must be almost invisible for users; the only thing they need to notice is value. The first thought of a user must be, “How could I live without these new features before?”
User data must be kept intact, users must not be logged out after an update. A picky user might forget the password, and just delete the app after facing the problem of remembering it.
“What’s new” paragraph is rather important for those who bother reading it, so it must not be neglected.
And now, to cut the long story short: no one knows what comes next year, month or even week, so updates are inevitable; but they must not turn into patches. They show the evolution of the software product. Only clearly valuable updates make end users happy.
