"Mobile" is not a single thing to test. A user reaching your product on a phone could be using a responsive web app, a native iOS or Android app, or a hybrid app that wraps web in a native shell. Each one has a different bug profile, different techniques, and different tooling. This lesson teaches you to recognise which one you are looking at and how to plan the right kind of mobile testing for each.
Three kinds of mobile experience
- Responsive web — the same site adapts its layout to the screen size. Built with HTML/CSS/JS, runs in the mobile browser. Easiest to test, easiest to ship to all platforms, but has no access to native features like push notifications, biometrics, or background processing.
- Native app — a separate codebase for iOS (Swift/Objective-C) and Android (Kotlin/Java). Best performance, full access to platform APIs, requires per-platform testing because the codebases are independent.
- Hybrid app — native shell (often React Native, Flutter, or Capacitor) running shared code. Faster to build than two natives but inherits bugs from both worlds — web rendering quirks and native lifecycle issues.
The right testing strategy depends on which you have. Responsive web is mostly browser-engine and viewport testing; native apps need real-device testing across OS versions; hybrid apps need both.
Responsive web — what to test
Responsive layouts adapt at breakpoints — specific screen widths where the design changes. The standard set is roughly:
- Mobile portrait: 320–479 pixels wide.
- Mobile landscape / small tablet: 480–767.
- Tablet portrait: 768–1023.
- Desktop: 1024 and up.
Test the layout at each breakpoint and just before and after it. The widest source of mobile bugs is layouts that look fine at exactly 768 pixels (the design width) but collapse at 767 or 769.
Touch versus click is the other half of responsive testing. A button that is comfortable to click with a mouse can be impossible to tap with a thumb. Apple's Human Interface Guidelines specify a minimum touch target of 44×44 pixels; Material Design uses 48dp. Testers should measure tap targets directly — anything smaller is a real-world accessibility problem.
Native apps — what to test
Native apps need their own test plan, separate from web:
- OS version coverage. iOS 15, 16, 17 each behave differently around permissions, back-grounding, and notifications.
- Device variations. A phone with a notch, fold, or punch-hole has different safe areas. Layouts perfect on an iPhone 15 Pro can break on an iPhone SE or a Samsung Z Flip.
- Permissions and lifecycle. Denied camera permission, app back-grounded mid-flow, a phone call interrupting payment — pure native testing, none of which responsive web has.
- Platform integrations. Push, biometrics, deep links, file pickers, camera, GPS, NFC — all OS-level code.
A reasonable native smoke set covers two iOS versions, two Android versions, two device sizes per OS, and the core flows.
Choosing the right testing approach
Real-device testing is the gold standard but it is expensive and slow. The decision tree below shows when each approach pays off.
The ordering matters. DevTools device mode is free and instantaneous — use it for the first 80% of layout and breakpoint testing on responsive web. Cloud platforms like BrowserStack and LambdaTest give you real browsers and OSes without owning hardware — use them for the next 15% of coverage. Real devices — yours or a shared lab — are the only option for the final 5% involving camera, GPS, biometrics, NFC, or push notifications. The cost-of-coverage curve gets dramatically steeper at each step, and the most common mistake is jumping straight to real devices when a free DevTools check would have caught the bug.
Common mobile-only bug patterns
Five patterns appear repeatedly on mobile and almost never on desktop:
- Tap targets too small. Buttons under 44×44 pixels are physically hard to tap, worst when stacked close together.
- Text not readable without zoom. Body text under 16 pixels forces iOS Safari to zoom on tap.
- Horizontal scroll. Any overflowing element creates a sideways scroll that surprises the user — usually a fixed-width element that ignored its container.
- Keyboard covers the input. When the on-screen keyboard appears it can hide the input being typed; the fix is to scroll the input into view, and many apps forget.
- Orientation changes lose state. Rotation should preserve form data, scroll position, and modal state. Apps that re-render from scratch feel broken.
A real example: a logistics app's navigation hamburger looked fine at 360 pixels but, at 320 pixels, three menu icons overlapped. Drivers on older or smaller phones could not access the main menu and had to call dispatch for everything.
⚠️ Common mistakes
- Treating responsive testing as a substitute for native testing. Responsive covers layout and browser behaviour. It does not cover platform integrations, lifecycle, or permissions. Native apps need their own coverage.
- Testing only the latest OS version. Real users span 2–3 major OS versions. A bug that only appears on iOS 15 reaches everyone who has not upgraded — often the highest-value enterprise users with managed devices.
- Skipping landscape orientation. Many products silently break in landscape because nobody ever tested it. Even if you support only portrait by design, verify the app handles a rotation gracefully rather than crashing.
🎯 Practice task
Spend 25 minutes auditing a mobile experience.
- Open a real product on your phone — your bank, your favourite e-commerce site, a healthcare app. Identify whether it is responsive web, native, or hybrid (a native app's transitions feel snappier and unique to the OS; a responsive page feels like a website).
- For a responsive product, open Chrome DevTools on your laptop, switch to device mode, and resize the viewport from 320px through 1280px. Note any layout that breaks at any width.
- Measure two tap targets with the DevTools ruler. Are they at least 44 pixels each side?
- Rotate the device (or rotate the emulated viewport) from portrait to landscape mid-flow. Does the layout adapt cleanly? Does any state get lost?
- Write down the three highest-impact bugs you found and what you would file in each one — title, environment, repro steps, and expected behaviour.