The Simple Checks We Do Before an App Update Goes Out
Automated test suites are good at catching regressions in logic. They're bad at catching the things that make a mobile release feel broken to a real user — a button under the notch, a form that doesn't handle the keyboard, a flow that's fine on Wi-Fi and falls apart on a bad connection.
Before any release, we run a manual pass on the lowest-spec device we support, on a throttled connection, with the OS's accessibility settings turned on. It catches problems the simulator never will.
The checklist has grown by one line every time something shipped that shouldn't have. That's the honest way most QA checklists get built.
Simulators and emulators are fast and convenient, and they're also lying to you about performance. A view that renders instantly on a developer's current-generation phone connected to office Wi-Fi can stutter, lag, or time out on a three-year-old budget device on a real cellular connection with real packet loss. Every release, we test on the oldest supported device in our matrix, not the newest one sitting on someone's desk.
Keyboard handling is the single most common thing that breaks silently. A form that looks correct in every screenshot fails the moment a real user taps into a text field and the keyboard covers the submit button, or the view doesn't scroll to keep the active field visible. This never shows up in an automated test because most test suites don't simulate the keyboard's actual screen real estate — it only shows up when a human physically taps through the flow.
Network conditions are the second blind spot. Most development and testing happens on fast, stable Wi-Fi, which means flows that depend on multiple sequential API calls look instant in every test run. Throttling to a realistic 3G-equivalent connection during manual QA exposes race conditions, missing loading states, and timeouts that a fast connection simply never triggers.
Accessibility settings turned on — larger text sizes, screen readers, reduced motion — catch a different category of bug: layouts that were built assuming a fixed text size, or interactions that depend entirely on a gesture with no alternative. These aren't edge cases; a meaningful share of any real user base has some accessibility setting enabled, and a release that hasn't been tested with them on is a release that hasn't actually been tested against its real audience.
The reason the checklist keeps growing instead of staying fixed is that every one of these categories was discovered the hard way, after something shipped broken to real users. We don't treat that as a failure of process — a QA checklist that never grows is one that stopped learning from its own mistakes. What matters is that each addition is specific enough to actually catch the next version of the same problem, not vague enough to be skimmed past.
None of this replaces automated testing — it catches a different class of bug entirely, the kind that only exists at the intersection of a real device, a real network, and a real human thumb.
