7 Tips For A Buttery Smooth Release
Some time ago, we faced a significant setback during one of our major app releases. A substantial portion of our user base experienced crashes immediately upon launching the app…
And it turned out, we're definitely not alone in this. recent data indicates that 56% of mobile app users have faced similar issues in the last six months. Among these, the most common problem reported was apps crashing or displaying errors, as experienced by 62% of users.
within the last 6 months? If so, what types? Source
Learning from our mistakes (and mistakes of others) is crucial, as it helps us avoid repeating them. Our screw-up led us to implement several new measures in our release process to ensure such issues do not recur.
Here are some of the key steps we have taken:
1/ Build A Beta Testers Community
The biggest benefit of beta testing is the ability to gather real-world engagement data from real users with a wide range of devices, OS, and browsers, and to spot the rare scenario bugs and crashes. The app might work perfectly on your tester’s iPhone; however, you’re most likely not shipping it with their device.
The best beta testers are recruited from your power users. They know the app very well, so they notice every oddity and bug in the new release. On top of it, they convey real usage feedback and often come up with great product ideas.
Beta users want to be involved in product development and want to feel like a part of the family. Therefore, it’s important to talk to them, discuss their ideas and keep them engaged.
2/ Phase Your Release
This is the smallest and easiest thing you can do to ensure you won’t screw your whole user base. Both the iOS App Store and Android Play Store allow you to gradually release your update across your audience.
On iOS, you can choose between a normal or phased release, which ensures automatic rollout of your update to all your users over a seven-day period. On Android, you can simply set up how many of your users (by percentage) you want to release your update to.
We usually start with a small single-digit percentage and monitor the Crashlytics and customer support carefully before the full rollout. In the case that anything goes wrong, the update will only affect a small amount of users and won’t cause any significant damage.
3/ Ensure Developers Care About the Quality
Many developers either don’t care about quality (they don’t understand the business consequences), or they’re too junior to handle the complexity required to design effective architecture and processes to ensure code quality.
Quality must be enforced; otherwise, it won’t happen. It’s important to encourage the quality-focused mindset and promote the will to improve. Don’t wait until you have a bug to walk through your code and processes. Start today. Reach out to your tech leads and discuss how to set up such a culture in your company.
4/ Approval from the QA & UX Team
Before any major release, make sure that both your QA and UX teams have enough time to get familiar with the release candidate version and approve the release. With their surveillance, you’ll be able to avoid 99% of the most common bugs, crashes, glitches and issues with the user flow.
Let your QA team focus on integration tests of the new features and regression tests of already existing features. Ensure your team has enough time to get familiar with the development plan and analyze the new functionality. They should be collaborating closely with your UX team and also you, the product manager.
“The goal of software testing is not to find bugs or to make software better. It is to make users happy.”
— Saša Stamenković
The UX team should ensure that no major flow in the app was damaged. Only improvements are allowed. Did new functionality solve the original issue? Is the feature understandable? Does it have a pleasant look and feel? For all these questions, user research will easily provide the answers.
5/ Other Stakeholders’ Awareness
I bet you know better than me who’s included in your product development process and who should know about a release in advance. I’ll just mention two important roles on your team who will benefit from the information: marketing and support.
If the marketing team is not involved in product development, let them know all details before the release so they have enough time to prepare the communication and content for the launch. Equally as important, ensure that the support team knows how the new functionality works, how to communicate it and how to properly troubleshoot.
On our team, everybody has a beta version installed well ahead of a release so they can get familiar with the new version before customers have access. A few days before release, we also host an extra short briefing to explain the new features, their business value and what kind of usage we expect.
6/ Release Often And In Smaller Chunks
I’m not a software engineer, so I won’t give you lectures about continuous integration and delivery, but I’ve observed one thing. Whenever we did a big bang release (lots of changes in a single release after a long development), it often ended with frustration and panic on the developers’ side, horror on my side and bugs on the user’s side. The more complex the release is, the more bugs you can expect.
Releasing smaller chunks regularly will help you monitor what’s wrong and identify the cause of the issue. Your developers will become significantly more confident about releases, and with needed automation, you’ll eliminate human errors.
7/ Implement Feature Flags
Feature flags are a powerful tool, enabling you to manage the deployment and visibility of features without needing to update the whole app. This makes releasing new features safer and easier to manage, because if something goes wrong, the feature can quickly be turned off.
It also allows you to test new ideas with some users first, to see how well these ideas work before everyone sees them. This is a smart way to make sure new features really help users and fit into the app well.
Conclusion
People like products that just work. No matter how many features your app has or how well-designed it is, it takes only one bug to ruin the user’s experience forever. This is why spending time on quality assurance is non-negotiable — because no software is ever written without bugs.
The economic logic backs this too; data shows that bugs caught during the design phase cost significantly less to fix than those found after release. This stark cost difference is a compelling reason to catch bugs as early as possible.
The techniques I’ve outlined won’t create perfect software immediately, but they’re about investing in a process that catches issues early, when they are least costly to fix. Over time, this approach will not only save on resources but also build a robust feedback loop to zero in on defects’ root causes.
By committing to this process, we cultivate a team that’s confident and well-prepared for major releases. Most crucially, we build a user base of satisfied customers — customers who trust in the app’s reliability and are eager to recommend it to others.
