On the phones your users have not the ones in the demo
Older Android builds, ageing iPhones, one bar of signal, battery saver switched on. A rack of new handsets on office wifi will not find what breaks in the field, and a bad mobile release cannot simply be rolled back.
In short: We test your app on real devices running the OS versions your analytics show, under the conditions phones are actually used in. Simulators are useful for speed and useless for the failures that generate one-star reviews, and on mobile a bad build waits in a review queue instead of being rolled back.
The devices people actually own
Development happens on the newest phone in the room. Your users are on something else. There are three-year-old handsets with a quarter of the memory, screens with different aspect ratios and notch positions, and Android builds two or three major versions behind. On those devices, layouts that looked fine start clipping, animations stutter, and the app gets killed in the background far sooner than anyone expected.
So the device list comes from your data, not from a catalog. We look at what your existing users run, weight by how much revenue or activity sits on each group, and add the oldest version you still claim to support. If you do not have that data yet, we say so and start with a defensible spread rather than pretending the list is precise. Testing the newest flagship is the least useful thing we could do with the time, because that combination is the one your developers already use every day.
Bad signal, not no signal
An offline phone is easy to handle. A request that hangs for a long time, then half succeeds, is what corrupts state and duplicates orders.
Interruptions mid-session
A call arrives during payment. An alarm fires. The user switches apps to copy a code and comes back. Each one is a lifecycle event your app has to survive.
Denied and revoked permissions
Camera refused. Location set to approximate. Notifications turned off later in settings. Plenty of apps crash on the revoke path because nobody tried it.
Resuming after days away
The token expired, the cached data is stale, the push registration lapsed and the app version is now behind. Cold resume is a common crash and a rare test.
What a simulator quietly hides
Simulators run on a desktop machine with a fast processor, unlimited power, a stable network and no other apps competing for memory. Every one of those differences removes a category of real failure. The network is perfect, so retry logic never gets exercised. Power is infinite, so battery saver never throttles the background work your sync depends on. Memory is plentiful, so the app is never killed while sitting behind another app, and the code that restores state on return is never run.
We use simulators for the fast repetitive checks, where they are genuinely efficient. But the sign-off pass happens on hardware, with the network shaped to something poor, the battery low, and interruptions fired deliberately. That is the pass that finds the bugs your reviews will be about.
Android and the battery managers
Android has a specific trap that catches teams repeatedly. Several manufacturers ship aggressive power management on top of the standard platform behavior, and it silently stops background work that the documentation says will run. Scheduled sync does not fire. An upload that was queued while the screen was off never finishes. Alarms slip by hours. Notifications arrive late or not at all. Your app never crashed, no error was logged, and the user simply thinks it is broken.
This does not show up on a stock developer device, which is exactly why it survives to production. We test background behavior on handsets from the manufacturers your user base actually carries, with their power settings at defaults, because default is what almost everyone has. Where the platform genuinely will not guarantee the work, we say so, and the fix belongs in how the app is built rather than in more testing.
A bad mobile release sits in a queue
On the web, a broken deploy is reverted in minutes. On mobile it is different in a way that changes how much testing is worth. The fix has to be built, submitted, and reviewed, and even an expedited review is out of your hands. Meanwhile the broken version is installed on phones, collecting ratings that stay attached to your listing long after the bug is gone. Some users will never update at all.
That is why we care about the release mechanics as much as the build. Staged rollout to a small percentage first, with crash rates watched before it widens. Server-controlled flags so a bad feature can be switched off without shipping anything. A forced-update path that actually works on old versions, tested rather than assumed. Automated smoke tests on release candidates through your build pipeline, so the obvious breakage is caught before a human even looks.
What we won’t do
We won’t test devices your users don’t have
A long device matrix looks impressive on an invoice and spreads the effort thin. We test the handsets and OS versions your analytics justify, and if the coverage list is short, that is the honest answer.
We won’t call a simulator run field-tested
Emulated passes are cheaper and faster, and we will use them where they earn their place. They do not count as release sign-off, and we will not describe them that way to make a deadline look reachable.
We won’t take responsibility for review timelines
We can prepare the build and the store metadata carefully to avoid the common rejection reasons. How long the review takes is not ours to control, and we will not help plan a launch that only works if approval is fast.
Has anyone used your app on a bad connection?
Send us a build and your device breakdown. We will come back with the device list worth testing, the field conditions we would put it through, and what we expect to find.
From your own analytics, weighted by how much activity and revenue sits on each group, plus the oldest OS version you still support. If that data does not exist yet, we start with a defensible spread and tell you it is an assumption rather than a measurement.
Are simulators good enough for most testing?
They are efficient for fast repetitive checks and they hide whole categories of field failure. Perfect networks, unlimited power and plentiful memory mean retry logic, battery throttling and background termination never get exercised. Release sign-off happens on real hardware.
Why does Android need extra attention?
Several manufacturers add their own power management on top of the platform, and it can silently kill background work that is supposed to run. Sync does not fire, uploads never finish, notifications arrive late. Nothing crashes and nothing is logged, so it survives to production.
How much does the store review process change things?
A great deal. A broken mobile build cannot be reverted like a web deploy, because the fix has to pass review while the bad version sits on phones collecting ratings. That is why staged rollouts and remote feature flags matter as much as the testing itself.
