Developer tools are not sufficient for testing mobile implementations

When developing web applications, the fastest way to test the mobile implementation is simply resizing your desktop browser window, or enable the device toolbar in the browser’s developer tools.

If you want an handy checklist for mobile testing, you can jump to the bottom of the article.

From many sides this is very inefficient, from the UX side, because you can’t use your fingers to interact, you can’t simulate the keyboard popping up; from the technical side, because the browser engine on desktop is different from the one on mobile, so you can’t be sure that what you see on desktop is exactly what you will get on mobile; and from the performance side, because the desktop browser is running on a more powerful machine, so you can’t measure the real performance of your mobile implementation, although you can enable throttling in the developer tools.

And how about the simulator with Xcode or Android Studio? They are better than desktop developer tools, but still not perfect. The simulator is running on your computer, so the performance is not the same as a real device. Remember, Simulators are not emulators. Simulators are mimicking the behaviour of a device, but they are not emulating the hardware. And they miss your finger interactions too.

This is a list of small checks you can do to improve your mobile testing experience:

Forms, check the input zooming

If your form inputs are less than 16 CSS pixels high, mobile Safari will zoom in when focusing the input. It is very annoying because when the focus is lost, the zoom level still remains, causing a bad user experience.

Ensure, with a media query, that all your form inputs are at least 16 CSS pixels high on mobile devices.

@media (pointer: coarse) and (width <= 48rem) {
  input,
  textarea,
  select {
    font-size: 16px;
  }
}

@media pointer coarse isn’t very commonly used. The meaning of it is to target devices with a coarse pointer, like fingers on touchscreens. If you want to read more about it, you can check the MDN documentation.

The width condition is optional, it is used to target small screens. You can omit or adjust it as you prefer.

The virtual keyboard is the big missing piece

When testing on desktop, you can’t simulate the virtual keyboard popping up. The virtual keyboard is a big deal on mobile devices, because it takes a big portion of the screen, and it can cause layout shifts, especially if your web app has input fields. It is very important, especially for forms, to test how your web app behaves when the virtual keyboard is open.

Touch targets

Ensure that all your touch targets (buttons, links, form inputs, etc.) are at least 48x48 CSS pixels. Apple call it “hit targets” in their Human Interface Guidelines. The guidelines is for IOS apps, but at the end, a web app is an app, isn’t it?

P.S. Google has similar similar recommendations, even better because it has css and JavaScript code snippets to help you.

Viewport settings

Have you ever met a website that on mobile looks zoomed out, with tiny text and small buttons? Probably the website is missing the viewport meta tag. Practically, you’re stuck on the web 2.0 era, when mobile browsers were not so advanced and the viewport tag was necessary to tell the browser how to render the page.

The viewport tag should be like this:

<meta name="viewport" content="width=device-width, initial-scale=1" />

This tag tells the browser to set the viewport width to the device width and to set the initial zoom level to 1. Find more on the mdn documentation about viewport.

Hardware problems

Yes, as I said you can simulate network conditions with developer tools, but you can’t simulate hardware problems like low battery, overheating, or background apps consuming resources. These factors can significantly affect the performance of your web app on mobile devices. And for those, you really need a real device. Even better, multiple real devices with different OS versions and hardware capabilities. Find your old relatives who carry the old phone that you gave them years ago, and use them for testing!

A vibrating computer?

There are some cool mobile features as the vibration API, that you can’t test on desktop. If your desktop vibrates, probably it is an earthquake, not the successful integration of the vibration API in your web app. You can simulate other APIs like the geolocation API with developer tools, but still, testing on a real device is always better.

App icons

Getting an icon that resembles your webapp as the one published in the app stores is important. You can find many tools online that helps you to generate app icons, my favorite is favicongenerator.io which allows you to preview how the icon will look before downloading it. After that, you need to inform the browser about the icon with the proper link tags in the head of your HTML.

Orientation changes

If your app provides horizontal videos (like YouTube, Netflix, etc.) the orientation changes are important. Rotating your monitor is not very handy, it can be a nice workout for your arms and for your neck. After few tries, you will really want to use a mobile device to test this feature.

Network conditions

The world isn’t covered in perfect 5G Wi-Fi. Your users might be on a spotty 3G connection in a train or completely offline in an elevator. While DevTools allows throttling, testing on a real device moving between network zones reveals how your app handles connection drops, retries, and offline states. Does it recover gracefully or stay stuck in a loading limbo?

Font rendering and legibility

Text that looks crisp on a 27-inch monitor might be unreadable on a mid-range phone under direct sunlight. Check color contrast and font weights on actual screens. Also, pay attention to font loading strategies—layout shifts caused by swapping fonts can be jarring on small screens and lead to accidental clicks (layout shifting). Keep in mind also font colors, last time I received feedback from a colleague that on his mobile device the text was barely visible because of low contrast between text and background colors.

Remote debugging

How can I access the developer tools of my mobile device? There are many ways to do it; if you have a Mac, you’re golden: you can test iPhones and Androids with Safari and Chrome respectively.

If not, you can use tools like inspect.dev that allow you to debug an iOS or Android device from a Windows or Linux machine.

Plus, if you use a frontend tooling like vite, you can also use the local network to access your development server from your mobile device without the need for USB cables.

Mobile testing checklist:

Here a handful checklist of points to test on mobile devices before shipping your web app:

input zooming
touch targets size
viewport settings
virtual keyboard behaviour
performance on real devices
hardware problems (low battery, overheating, background apps)
mobile-specific APIs (vibration, geolocation, etc.)
app icons
orientation changes (portrait/landscape)
network conditions (3G, 4G, offline)
font rendering and legibility