Chrome DevTools has a device emulation mode. It is useful for development. It is dangerously misleading for quality assurance.
Emulators approximate the viewport dimensions of a device. They do not replicate the rendering engine, the touch behavior, the performance characteristics, or the hundreds of small differences that make a real iPhone feel different from a pixel-accurate rectangle in a browser window.
The device drawer
Our studio maintains a collection of physical devices. Not the latest flagships — the devices our clients’ actual users carry. An iPhone SE. A Samsung Galaxy A series from two years ago. An iPad Mini. A Pixel 6a. A Kindle Fire tablet.
These are mid-range and older devices with limited processing power and real-world network conditions. They are the devices where performance problems, rendering bugs, and touch target issues actually surface.
What emulators miss
Touch targets. A button that is easily tappable with a mouse cursor in an emulator may be frustratingly small on an actual thumb on an actual phone. The minimum touch target should be 44x44 pixels, but you cannot feel whether that is sufficient without a real finger on a real screen.
Scroll behavior. iOS Safari has momentum scrolling, rubber-banding at the top and bottom of the page, and a disappearing address bar that changes the viewport height. None of this is replicated in Chrome’s device emulation.
Performance. A page that loads instantly on your development machine with a wired connection will load differently on a three-year-old phone over a congested mobile network. Real device testing reveals jank, dropped frames, and slow interactions that the emulator hides.
Font rendering. Fonts look different on every operating system. Subpixel rendering, hinting, and font smoothing vary between macOS, Windows, iOS, and Android. A design that looks crisp on macOS may look heavy or blurry on Windows.
Our QA checklist
For every project, we test on at minimum: latest iOS Safari, latest Android Chrome, one generation behind on each, one budget Android device, desktop Chrome, desktop Firefox, and desktop Safari.
We test these scenarios for every major page and every interactive component. Not a cursory glance — a systematic walkthrough that includes form submission, navigation, animations, and error states.
The one-minute test
Before any stakeholder presentation, we do the one-minute test: hand the phone to someone who has not seen the project and watch them try to accomplish a single task. Do not explain anything. Do not give hints. Just observe.
The one-minute test catches more usability problems than any amount of internal review. Fresh eyes on a real device reveal what familiarity hides.
Accessibility on real devices
Screen readers behave differently on different devices. VoiceOver on iOS, TalkBack on Android, and NVDA on Windows each have their own interaction patterns and quirks.
We test with VoiceOver on at least one iOS device for every project. Not because we are experts in every screen reader, but because testing with one real assistive technology catches the most common issues: missing labels, incorrect heading hierarchy, and non-functional keyboard navigation.
Testing on real devices is slower and more expensive than using emulators. It is also the only way to know how your users will actually experience the product.
