← Back to writing

2026-09-20

The Bug That Only Existed on One Phone

We had a checkout flow that passed on every device in our test matrix: iOS simulators, a handful of Android emulators, browser-based responsive checks, all green. Then a support ticket came in: a user on a specific mid-range Android phone couldn't complete checkout. The submit button was there, visible, tappable, and did nothing.

Nobody on the team could reproduce it. Not on the emulator running the same OS version. Not on a different physical phone from the same manufacturer. It took borrowing the exact device model, with the exact OS build, to finally see it: a keyboard overlay resize bug specific to that phone's manufacturer skin, which shifted the submit button just far enough off-screen that taps landed on nothing. Structurally invisible in every screenshot, because the screenshot tool captured the intended layout, not what the keyboard overlay was actually doing to it.

Emulators test the platform. They don't test the device.

An Android emulator is a faithful simulation of stock Android. What it doesn't simulate is Samsung's One UI, or a budget manufacturer's aggressive battery-saving throttling, or a screen with unusual aspect-ratio notches, or how a specific chipset handles animation timing under load. iOS is more uniform since Apple controls both hardware and software tightly, but Android's fragmentation means "tested on Android" can quietly mean "tested on the one Android configuration we happened to have."

What actually changed how I test mobile flows

I stopped treating "mobile testing" as one checkbox and started treating it as at least three separate questions: does this work on iOS, does this work on stock/reference Android, and does this work on the manufacturer-skinned Android devices real users are actually holding. That third one is the one most teams skip, because it's the most annoying to staff. You can't emulate a manufacturer's skin, you need the actual hardware, or a device cloud service that carries it.

It also changed what I look for in test results. A green checkmark on an emulator run tells you the platform behaved correctly. It doesn't tell you a specific physical device, with its own quirks, will behave the same way. On anything customer-facing, at some point the checklist has to leave the simulator and touch real, unglamorous, slightly-outdated hardware, because that's what's actually in your users' hands.