There is a reliable pattern in mobile projects: the app works beautifully in the studio and badly in the wild. Not because anyone was careless, but because the devices are different in ways that matter. That is why working out how to test an app before launch starts with a plain question: whose phones are you testing on?
What is different out there
Age. A four-year-old phone has a slower processor, less memory and a version of Android two releases behind. Your animation stutters, your images take a second to decode, and the operating system kills your app in the background far more eagerly.
Storage and battery. A phone at ninety-eight percent full behaves differently: caches fail, downloads fail, and the failures are ones nobody wrote a screen for. Battery saver throttles background work and delays notifications.
Screen shapes. Not just size — notches, punch holes, gesture bars, and a font scale someone set to the largest option because they cannot read the smallest. That last one breaks more layouts than any device.
Manufacturer behaviour. Some vendors are aggressive about killing background apps and will silently prevent notifications. This is not in any specification and only shows up on the actual device.
How to test an app before launch without buying a lab
You do not need thirty handsets. You need three:
- The newest common iPhone in your market.
- A mid-range Android from three or four years ago — the single most valuable phone you can own, because it is what a large share of your customers are holding.
- One phone with large font scale and a nearly full storage, which you can configure on either of the above.
Add automated tests that drive the real app on a real device or emulator in your pipeline, and you catch the structural failures — session expiry, background kill, permission denied — without owning a shelf. Why a mobile suite costs more than a web one is covered in app testing cost on mobile.
The cheapest fix is a decision, not code
Decide early which operating system versions you support and write it down. Supporting everything back to Android 8 is a legitimate choice with a cost. Supporting only the last three versions is also legitimate and cheaper. What is expensive is not deciding, discovering the problem after launch, and retrofitting support into a design that assumed the newest thing.
And ask any studio you are considering: which devices do you test on, and what happens in your suite when the app is killed in the background? The answer tells you quickly whether they have met your customers' phones or only their own. Ours run on real devices rather than emulators; what that covers is listed here, and it is why a release includes a device suite rather than a promise.
On the same decision, from another angle: do you need both app stores on day one?.