The Essential Parts of a Mobile App Launch Strategy
Releasing a mobile app is not an easy task. Once an app is rolled out to customers, there is no way of rolling it back. Imagine a native mobile app as a good old burned CD that was shipped as a part of a magazine. Once it’s burned and shipped, that CD can’t be altered. The same applies for native mobile apps. Therefore, a solid mobile app launch strategy is key to success for every company.
Gather Information About the Development & Testing Process
The first thing a mobile test or release manager should do is gather information from the client or the internal development department about the sprint cadence and internal milestones. It’s also important to know if an internal testing department is involved, or if external testing providers are used in the development cycle. Often, internal or external beta testing communities can help with the launch of an app.
The gathered information will help to organize the rollout of the app to customers.
Gather Information About the App Release Version
Every new app release should contain meaningful release notes. The release notes will inform the customers about the new app update and what they can expect from the release. It’s also a first place customers can look for changes. Therefore, this information is very important to gather from the app development team. Depending on the feature set, it might happen that a completely new section is added or is getting removed in the updated version. In that case, the store description must be checked and updated. This includes texts, images and app videos. If this information is updated, it’s important to abide by corporate branding guidelines.
Development and Testing Activities Have Finished
Before submitting a new version of the app to an app store, all development and testing activities must be complete. Testing should be a constant part of the software development process. However, at the end of the development phase, a mobile app should have another round of exploratory testing to double-check that new and critical features are working as expected. Furthermore, the developers and testers must run the complete automated suite to check that all tests are green. Without this information, it’s not recommended to submit the new app version as the likelihood of bugs is high.
Verify the Release Checklist
The last step before going live with the new app version is to verify the release checklist. Every company or team should have a mobile app release checklist to ensure nothing has been missed. The release checklist should contain topics like:
- All tests have been executed and passed
- New features have been covered with new automated checks
- The update test has been performed
- All APIs and backend services are up and running
- Critical paths like login, registration or upsell points have been inspected
- Release day is clear to everyone
- Release notes and images are in place and ready for submission
- To how many customers will this app version be rolled out?
- Who is taking care of the release and the post release monitoring?
If all the points are clarified, the new mobile app version can be released.
Post Release Monitoring
Once the app has been released to customers, it’s very important to perform post release monitoring. This includes live monitoring of several channels like the app store reviews, checking the crash reporting tools for anomalies, as well as ongoing bug tracking. If the new app version introduced critical bugs, the customers will notice them and will be quick to provide bad reviews. In these cases, someone from the team must react and provide (if possible) solutions to the customers.
Furthermore, the crash reporting tools must be checked for new crashes and other log anomalies. It’s also recommended to compare the previous app release crashes with the new rolled-out version once enough customers have installed the app. This gives the team a sense if the new app version has improved or gotten worse. As a last post release monitoring channel, the implemented tracking should be checked. With this information, a team can see if the features are still being used or if there are possible usage issues.
