How to Test an App Across Multiple Screen Sizes

Test an app across screen sizes by building a risk-based matrix of the platforms and configurations you support, then combine previews or emulators, real task checks, automated interaction tests, screenshot comparisons, accessibility checks, and selected physical-device testing. Cover compact, medium, and expanded available widths; relevant orientations and aspect ratios; larger text; and configuration changes such as resizing, rotation, multi-window, or moving between foldable displays.

A few device presets are useful samples, not proof that an app works everywhere. Test both appearance and behavior: navigation, input, saved state, and task completion should still work after a resize or configuration change.

1. Define the screen-size test matrix

Start with the devices and user journeys your app claims to support. Choose configurations by available space and behavior, not device names alone. A practical baseline is:

Layout class	Example configuration	What to inspect
Compact	Narrow phone window; portrait	Clipping, crowded controls, navigation, keyboard overlap, long labels
Medium	Larger phone or narrow tablet window	Breakpoints, spacing, content hierarchy, unnecessary stretching
Expanded	Tablet, desktop browser, or large app window	Multi-column layout, maximum content width, whitespace, pointer interaction
Alternate orientation	Landscape or another supported aspect ratio	Short available height, overlays, scrolling, orientation state preservation
Resizing/configuration	Split screen, resizable window, fold/unfold transition	Reflow, recreation, saved input, navigation and transient state
Accessibility configuration	Larger text and relevant assistive technology	Readable content, visible controls, focus order, labels, task completion

Include critical screens and journeys: launch, primary navigation, forms, save or submit, return to a previous screen, empty and error states, long content, and dialogs or overlays where your app uses them. Record which configurations matter for each journey so the matrix stays tied to user risk.

For Android, account for different aspect ratios and window sizes. Android 10 (API 29) and later support a wide range of aspect ratios, including examples from 21:9 folded displays to a 1:1 unfolded display. See the official responsive and adaptive layout guidance and screen and window size testing guidance.

2. Preview the smallest and largest layouts early

Before writing a large test suite, inspect the smallest and largest supported layouts. Resize gradually across breakpoints rather than checking only named presets. Look for abrupt changes, overlapping controls, clipped text, awkward whitespace, unintended horizontal scrolling, and actions pushed out of reach.

Use representative real content, including long names, translated strings if applicable, empty states, and large data sets.
Check the on-screen keyboard, dialogs, menus, and other overlays at short and narrow sizes.
Verify that content reflows without losing its hierarchy or making the main action hard to find.
Repeat with larger text settings where supported; do not assume a layout that fits at the default text size remains usable.

On Apple platforms, preview across supported devices, orientations, localizations, and text sizes. Apple recommends checking the smallest and largest layouts early and using simulated devices to spot clipping. Some behavior is best inspected on real hardware. See Apple’s layout guidance.

3. Use previews, emulators, and browser viewport tools

Android

Use Android Studio previews for quick layout iteration and the Android Emulator for interactive checks across representative dimensions. Android Studio’s resizable emulator can switch among common display configurations. If suitable hardware is not available locally, Firebase Test Lab provides hosted device access. These tools broaden coverage; they do not guarantee that every manufacturer’s device behaves identically.

Apple platforms

Use previews and simulated devices to inspect the supported device classes, orientations, and text sizes. Add physical-device checks when hardware-specific behavior, input, rendering, or performance could affect a critical journey. Apple’s Xcode previews help with iteration, while accessibility checks should follow the tasks people need to complete.

Web apps

Safari Responsive Design Mode lets you inspect a page at different viewport widths, heights, and pixel ratios. It is a viewport preview, not an exact reproduction of every device’s rendering or behavior. Validate important browser-specific and touch interactions in actual browsers and, where risk warrants, on physical devices. See Safari developer tools.

When comparing approaches, consider configuration breadth, hardware fidelity, repeatability, visual versus interaction coverage, accessibility coverage, maintenance cost, and whether the method runs a user journey or only renders a static screen.

4. Run the same user journeys at meaningful sizes

At each layout class, perform the critical tasks rather than stopping after the first screen renders. A repeatable manual pass can follow these steps:

Launch the app and confirm the initial screen fits.
Navigate to a critical feature and exercise its primary controls.
Enter data, submit or save it, and confirm the result.
Resize, rotate, enter or leave multi-window mode, or trigger the supported fold transition.
Confirm the current screen, entered data, navigation position, and task state are preserved as intended.
Repeat with the keyboard open and with relevant text-size or assistive-technology settings.

Check touch input on touch devices, and mouse, keyboard, or external input when those are supported. For Android, state preservation across configuration changes is a specific concern: test what happens when the activity or UI is recreated, not only when its first layout appears.

5. Automate behavior and visual regression checks

UI behavior tests and screenshot tests catch different problems. Behavior tests verify that elements exist, actions work, and state changes as expected. Screenshot tests compare a rendered screen with an approved image and can reveal visual regressions. Use both for representative screens and important flows; keep manual task checks for behaviors that are difficult to model reliably.

For each screenshot test, control the conditions that affect pixels: window dimensions, pixel density, orientation, app data, system bars, text scale, locale, animation state, and any remote content. Review an unexpected difference before updating the approved image so a real regression is not accepted as a new baseline. Keep a small, purposeful set of screenshots for the highest-risk layouts instead of generating snapshots for every possible size without a review plan.

Android’s official guidance recommends automated tests to verify consistent behavior and appearance across window and screen sizes. It highlights visual attributes and state preservation across configuration changes. Read Android’s testing guidance.

6. Include accessibility and text-size coverage

Accessibility belongs in the same test matrix as screen dimensions. On supported platforms, increase text size and check that primary tasks remain completable, controls stay visible, and navigation still makes sense. Check labels, focus order, contrast-related settings, captions and media controls where relevant, and the behavior of assistive technologies your app supports.

Apple recommends identifying each screen’s main tasks and testing relevant visual and media accessibility settings and assistive technologies, including VoiceOver, Voice Control, and Switch Control. Use the settings and technologies that apply to your app and test task completion, not only whether a screen can be opened. See Apple accessibility guidance.

7. Choose when to use physical devices

Emulators and viewport previews are efficient for broad, repeatable iteration. Select physical devices when a critical feature depends on hardware, manufacturer-specific behavior, OS integration, actual touch or input behavior, or rendering and performance that a simulation may not reproduce. Hosted-device services can help when those devices are unavailable in-house.

No single emulator, viewport preset, or physical device demonstrates compatibility across an entire ecosystem. Pick physical checks based on user impact and technical risk, then keep the broader configurations in automated or simulated coverage.

8. Keep the suite fast, reliable, and affordable

Prioritize by risk: run quick previews and core layout checks during development; reserve broader device coverage for changes and journeys with higher impact.
Control test inputs: fixed data, fonts, locale, viewport, and animation state reduce screenshot noise.
Separate failure types: identify whether a failure is a layout mismatch, interaction failure, lost state, device setup issue, or flaky external dependency.
Limit redundant snapshots: capture representative breakpoints and important screens, then add a case when it covers a distinct risk.
Use hosted devices selectively: they expand hardware coverage without requiring every device onsite, but still need a maintained test plan.
Review the total cost: include setup and maintenance time as well as device or hosted-test usage. Choose coverage that addresses actual supported configurations.

ScreenshotNeo is a website screenshot API and MCP server for developers, useful for checking responsive web pages when you need repeatable captures at chosen viewports. A screenshot of a web page can support visual review, but it does not replace app interaction tests, accessibility checks, or physical-device testing. Learn more at ScreenshotNeo.

9. Troubleshooting common failures

Symptom	Likely cause	Fix
Text or controls are clipped	The layout assumes a minimum width or default text size	Check the smallest width and larger text settings; let content wrap or reflow and verify the primary action remains reachable.
Layout breaks only in landscape or split screen	The design relies on a fixed height or device orientation	Test the actual available window size and short height; avoid assuming the app always fills a full portrait screen.
Entered data disappears after resize or rotation	State is tied to a recreated view or activity	Preserve the required UI and business state through configuration changes, then test the full journey after recreation.
Screenshot tests fail intermittently	Animations, time, remote content, fonts, or asynchronous loading vary	Use deterministic data, wait for the relevant content, stabilize animation and time-dependent elements, and compare under fixed rendering conditions.
Preview looks correct but a device does not	Simulation differs in hardware, OS, browser, font rendering, or input behavior	Reproduce on a representative physical device and add a targeted regression case for the behavior.
Safari viewport preview differs from an iPhone	Responsive Design Mode approximates viewport dimensions and does not reproduce all device behavior	Use it for viewport iteration, then validate important behavior on actual hardware and browser versions you support.
Large text makes a flow impossible to finish	Only visual fit at the default size was checked	Test the relevant accessibility setting through the whole task; fix scrolling, wrapping, control sizing, labels, and focus order as needed.

10. Or skip the browser setup

For a responsive web page, ScreenshotNeo can capture a URL through one API request. The request returns an image or PDF; use a viewport option when you need to compare a particular screen size. See the ScreenshotNeo API documentation for request options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

Cookie and consent banners, newsletter popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed, and response headers identify the page verdict and billing outcome. Its MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

Frequently asked questions

How many screen sizes should I test?

There is no universal count. Cover the distinct compact, medium, and expanded layouts and configuration changes your app supports, then add cases for risks that representative configurations do not cover.

Can an emulator replace real devices?

It can provide broad, repeatable coverage, but it may not reproduce all hardware, OS, input, performance, or rendering behavior. Use physical devices for selected high-risk checks.

Are screenshot tests enough?

No. They detect visual differences, while interaction and state tests verify behavior. Run representative user journeys and accessibility checks as well.

Does Safari Responsive Design Mode test a native iOS app?

No. It previews web pages at simulated viewport settings. Use platform tools for native app layouts and validate hardware-specific behavior on devices when needed.