Why mobile bugs escape web-first QA teams

I've watched strong web QA teams ship genuinely bad mobile releases, and it's almost never for lack of effort. It's that web testing trains a specific mental model — a page loads, you interact, you assert — and mobile breaks that model in ways nobody warns you about. The bugs escape not because the testers are weak, but because the assumptions are invisible. Here are the ones that do the most damage.

Assumption 1: the app starts fresh

On the web, every test more or less starts from a clean page load. Mobile apps don't. They get backgrounded, resumed hours later, killed by the OS to reclaim memory, and resumed again from a serialized state. The bug that never appears in a clean run appears constantly here: stale data after resume, a crash restoring a screen that no longer exists, a half-finished form lost on backgrounding. If your mobile testing always starts by launching the app fresh, you're testing the one path users take least.

Assumption 2: the network is there

Web QA usually runs on office wifi, and so the network is treated as a constant. On mobile it's a variable: users walk into lifts, switch from wifi to cellular mid-request, sit on a train with two bars. The interesting bugs live in the transitions — a request fired on wifi that completes on cellular, an offline action that double-submits when connectivity returns, a spinner that spins forever because the failure case was never handled. "Works on my phone" usually means "works on my phone, on my wifi, in my building."

Assumption 3: the app owns the screen

A web page rarely gets interrupted. A mobile app gets interrupted constantly — a phone call, a push notification, a "low battery" dialog, the keyboard sliding up and shoving the layout, the user rotating the device mid-form. Each interruption is a lifecycle event that can lose state or break the layout, and none of them have a web equivalent you'd think to test.

Assumption 4: permissions are granted

On the web, you don't think about whether the user "granted" access to a form. On mobile, camera, location, photos, notifications, and contacts are all permissions the user can deny, grant once, or revoke later in settings while the app is backgrounded. The denied-permission and revoked-mid-session paths are where mobile apps crash or dead-end — and they're invisible if you always tap "Allow."

Assumption 5: there's one browser

Web teams test a handful of browsers and feel covered. Mobile fragmentation is a different scale: OS versions users won't upgrade, screen sizes from tiny phones to tablets, manufacturer skins that change behaviour, and the big one web has no equivalent for — the app update itself. Users run the old version for weeks. Does the new app handle data the old one wrote? Does a forced-update flow actually work? Web ships one version to everyone; mobile runs every version you've ever shipped, simultaneously.

What to test instead

You don't fix this with more device coverage. You fix it by testing the things web never made you think about: lifecycle (background/resume/kill), network transitions, interruptions, permission states, and the upgrade path. For the tool side of this — real devices versus emulators, and the Appium/Detox/Maestro question — see the mobile testing tool comparison. For the specific defect classes, the common bugs library catalogues the notification, data, and time/date bugs that hit mobile hardest.

The web-team's mobile blind spots

• Background the app mid-task and resume — is state intact?
• Kill the app from the OS and relaunch — does it restore correctly?
• Switch wifi ↔ cellular mid-request; go offline and come back
• Interrupt with a call / notification / rotation during a flow
• Deny a permission, then grant it; revoke one while backgrounded
• Install the old version, write data, then upgrade in place
• Force an app-update flow and confirm it actually completes