An app that works on the development team’s phones has proved very little. Those phones are recent, fast, on good Wi-Fi and owned by people who know exactly where to tap. Your customers have none of those advantages.
Pick a device matrix, and write it down
It is impossible to test on every phone, so the first job is to choose which ones stand for the rest. A good matrix covers the oldest operating system version you support, the newest, a small screen, a large one, a low-memory Android device and at least one phone from the manufacturers most common with your audience.
Writing the matrix down matters more than it sounds. It turns "we tested it" into a statement someone can check, and it makes the gaps visible before a customer finds them.
Real life interrupts
Phones ring. Notifications arrive. Users switch to another app to copy a code, lose signal in a lift, or lock the screen in the middle of a payment. Each interruption is a chance for the app to lose data, repeat an action or crash on return.
So we test the interruptions directly: a call during upload, airplane mode during checkout, the app sent to the background for an hour and then reopened, the phone rotated on a screen that was never designed for landscape.
Permissions and first run
The first minute of an app is where most people decide to keep it or delete it, and it is also the least tested part, because the team stopped seeing it months ago.
Test a fresh install every time. Refuse every permission and see whether the app still makes sense. Grant location but deny notifications. Turn on the largest system text size and dark mode. An app that only works when the user agrees to everything is not finished.
Slow networks, not just no network
A missing connection is easy to detect. A bad one is harder: requests that take twenty seconds, time out halfway or succeed on the server while the app thinks they failed. That last case is how customers get charged twice.
Both iOS and Android development tools can simulate poor networks. It takes an afternoon and finds problems that would otherwise surface as angry reviews.
Test the release, not just the build
The version that reaches the store is not quite the version on a developer’s machine. Release builds are optimised differently, use production keys and talk to production servers. Testing a release build through TestFlight on iOS and a testing track on Google Play catches the class of bug that only exists in the shipped app.
Store review is part of this. Both stores reject apps for broken links, missing account deletion, unclear data use and placeholder content. A short review of their current guidelines before submission is cheaper than a week of back and forth.
Watch what happens after release
No test suite catches everything. Crash reporting and a staged rollout, releasing to a small share of users first, turn the first days after launch into a controlled test instead of a public one. If a crash appears, the release is paused before most people ever see it.
