Visual Testing for Progressive Web Apps (PWA): Test Them Like Apps, Not Websites

Key Takeaways

PWAs are not simple websites: they have specific visual states (offline, standalone, installation, splash screen) that standard web tests overlook
The user experience of an installed PWA is judged by native app standards, not website standards
Visual testing must cover the transitions between online and offline modes, standalone rendering, and specific elements like splash screens and installation prompts
Without visual coverage of these states, you're shipping what looks like a native app but is actually a broken website

A Progressive Web App (PWA) is defined by the W3C as "a web application that uses modern web technologies — notably Service Workers, the Web App Manifest, and HTTPS — to deliver a reliable, fast, and engaging experience to users, comparable to a native application, directly from the browser or after installation on the device" (W3C, Web App Manifest specification).

This definition is technically accurate. But it misses the point: from the user's perspective, an installed PWA is not a website. It's an application. It shows up in the dock, in the taskbar, in the app switcher. It has its own splash screen, its own window, its own behavior when the network drops.

And that's exactly where the problem lies. If your users perceive your PWA as an app, they judge it with app-level expectations. But if you test it as a simple website, you're letting entire categories of visual bugs slip through the cracks.

PWAs Have Visual States That Websites Don't

The Online State: The False Friend

The online state is what everyone tests. It's your PWA in a browser, with a stable network connection, behaving exactly like a regular website. Everything works, everything displays, data loads normally.

The trap is believing that testing this state is sufficient. It's like testing a mobile app only on Wi-Fi in your office and considering the coverage adequate. The online state is the starting point, not the destination.

The Offline State: The True Maturity Test

When a PWA loses network connectivity — or when the user opens it in airplane mode — the Service Worker takes over. Cached pages are served from local storage. Unsynced data is managed locally. Features that require the network are gracefully degraded.

From a visual standpoint, the offline state is a minefield. Here's what can go wrong, and what systematically flies under the radar:

Uncached pages display an error page. If your caching strategy doesn't cover all routes, the user sees a blank page, a browser error, or a fallback page. Have you designed that fallback page? Have you tested it visually? Across all viewports?

Images don't load. Your cache contains the HTML and CSS, but uncached images display a broken placeholder, a broken link icon, or worse, empty space that disrupts the layout. Visual testing is the only reliable way to verify that the offline state is visually acceptable.

Dynamic components degrade. A chart that needs real-time data, a news feed, an embedded chat — in offline mode, these dynamic content components must display an explicit and visually consistent degraded state. Not an infinite spinner, not an empty container, not a technical error message.

Network status indicators appear (or don't). If your PWA displays a "You are offline" banner at the top of the page, that banner is part of the user experience. Its appearance, positioning, and interaction with the rest of the layout must be visually tested.

The Splash Screen: The First Milliseconds Matter

When a user launches your installed PWA, the first thing they see is not your home page. It's the splash screen, automatically generated by the browser from your Web App Manifest data (name, icon, background color).

This splash screen is often the neglected child of design. And that's a mistake. It defines the first impression of your app at every launch. If the icon is pixelated, if the background color doesn't match your app's theme, if the text is truncated, the user immediately feels a disconnect that erodes trust.

The splash screen is particularly tricky because its appearance depends on the browser and OS — a well-known cross-browser challenge. Chrome on Android generates it differently from Safari on iOS. The expected icon sizes differ. The handling of margins and centering varies. You need visual captures on the platforms you target.

The Installation Prompt: The Conversion Moment

The installation prompt — the banner or modal inviting the user to "Add to Home Screen" — is a critical conversion moment. It's the equivalent of the "Download" button in an app store. Its visual appearance directly influences the installation rate.

Many PWAs use a custom prompt (by intercepting the beforeinstallprompt event) rather than the browser's native prompt. This custom prompt is a component of your application. It must be visually tested like any other component — across all viewports, all themes, all contexts.

But the native prompt varies by browser and version. You don't control its appearance, but you do control what happens around it: the page content in the background, the positioning of your elements, the behavior when the prompt pushes content downward. All of this deserves visual verification.

Standalone Mode: The Interface Without Browser Chrome

When your PWA is installed and launched from the home screen, it opens in "standalone" mode: no address bar, no tabs, no browser navigation buttons. The application fills the entire available screen (except for the system status bar).

This change in environment has direct visual implications.

The available space changes. Without the address bar, your application has 50 to 80 extra pixels in height. If your layout relies on fixed heights or viewport calculations (100vh), the rendering can be noticeably different in standalone versus browser mode.

The safe area comes into play. On devices with a notch or Dynamic Island, the safe content area is different in standalone mode. Elements positioned at the top or bottom of the screen (fixed headers, navigation bars, FABs) can be partially hidden if safe areas are not properly handled.

Navigation changes. Without a browser "back" button (notably on iOS), your application must provide its own navigation. If a user can end up on a page with no way to go back, that's a major UX bug — and visual testing can detect it by verifying the consistent presence of navigation elements.

Interactions with the system status bar. The color of your status bar (defined in the manifest or via the theme-color meta tag) must harmonize with your header. A white header with a black status bar creates an unsightly visual break.

The Problem with Standard Web Tests

They Only Test One State

The vast majority of test suites — including visual tests — only test the online state in a browser. It's the default state, the simplest to set up, and the most stable. But it's also the state that most resembles a simple website.

If you only test this state, you're testing the least demanding version of your PWA. You're verifying that your application works under ideal conditions. That's necessary, but insufficient.

They Ignore the PWA Lifecycle

A PWA has a lifecycle that websites don't have. Installation, Service Worker updates, background synchronization, coming back online after an offline period — each of these transitions can trigger unexpected visual states.

When the Service Worker updates while the user is using the application, a "New version available — Reload" banner may appear. The appearance of this banner, its positioning, its interaction with the content — all of this must be tested.

When the application comes back online after an offline period, data synchronizes. During synchronization, the interface may display loading states, progress indicators, data conflicts. These transient visual states are often overlooked and often broken.

They Don't Reproduce the Standalone Context

Opening your PWA full-screen in a browser is not the same as opening it in standalone mode. The dimensions are different, the safe area handling is different, the overscroll behavior is different. A test run in Chrome DevTools with a simulated viewport does not faithfully reproduce the real environment of an installed PWA.

How to Properly Visual Test a PWA

Map Your Visual States

Before configuring your tests, explicitly list all visual states of your PWA. At minimum, you should cover:

The online state in browser mode. This is your standard web baseline. Every page, every viewport.

The online state in standalone mode. The same pages, but in the installation context. Check for layout differences related to the absence of browser chrome.

The offline state — cached pages. When the user accesses a page available in the cache without a connection, what do they see? Is the data complete? Are images present?

The offline state — uncached pages. When the user accesses an uncached route without a connection, is the fallback page visually correct? Does it offer a path back to cached content?

The online-to-offline transition. Does the offline banner appear correctly? Do dynamic components degrade visually in a graceful manner?

The offline-to-online transition. Is resynchronization visible? Does updated data display without visual artifacts?

The splash screen. On target platforms (Android Chrome, iOS Safari, Samsung Internet), is the splash screen visually correct?

The installation prompt. Is your custom prompt (if you have one) visually correct in all contexts?

Automate Network State Changes

To test the offline state, simulate network loss programmatically. The Chrome DevTools Protocol allows offline simulation, and tools like Playwright natively support network condition manipulation.

The typical sequence: load the page online, verify visually, cut the network, reload or navigate, verify the offline state visually. This sequence must be automated and reproducible.

Test Standalone Mode Without a Physical Device

Using Chrome's "app" launch option (a window without browser chrome) is the most pragmatic approach. It's not identical to a real installed PWA, but it's close enough to detect layout regressions related to the absence of the address bar.

For safe areas, visually verify elements positioned with env(safe-area-inset-top) or env(safe-area-inset-bottom) with values matching your target devices.

iOS Specifics: A World Apart

Let's be clear: Safari on iOS is the most problematic browser for PWAs. And it's probably the most important platform for your users.

Despite significant progress since iOS 16.4 (which introduced push notifications for PWAs), Safari still lags behind Chrome in PWA support. The splash screen is handled differently. Standalone mode has specific behaviors. Viewport and safe area handling is stricter.

This means your visual tests must include Safari iOS as an explicit target, not as an afterthought. The rendering differences between Chrome Android and Safari iOS for the same PWA are often substantial and surprising.

According to StatCounter data for 2025, Safari represents approximately 27% of the global mobile browser market. Ignoring its PWA specifics means ignoring a quarter of your potential users.

What Delta-QA Brings to PWAs

Delta-QA dramatically simplifies PWA visual testing through its no-code approach. You don't need to write scripts to simulate the different states of your PWA — you configure your scenarios visually.

Delta-QA's ability to test across different viewports is particularly relevant for PWAs, which must work equally well on a smartphone screen in standalone mode and on a desktop screen in a browser. A single no-code tool covers the entire spectrum.

And because PWAs update frequently (updates are transparent, without going through an app store), testing cadence must be high. Integrating Delta-QA into your CI/CD pipeline ensures that every deployment is visually verified before reaching your users.

FAQ

Aren't standard visual tests enough for a PWA?

No. Standard visual tests cover the online state in a browser. For a PWA, that corresponds to the least representative state of the real user experience. The offline state, standalone mode, splash screen, installation prompt — these are PWA-specific visual states that standard web tests overlook. If you only test the online state, you're leaving the majority of PWA visual risks uncovered.

How do you simulate the offline state in automated tests?

You can use the Chrome DevTools Protocol (CDP) capabilities to simulate network loss programmatically. Testing frameworks like Playwright offer native methods for this. The typical sequence: load the page normally, cut the network via the API, then navigate or reload to observe offline behavior. Capture screenshots at each step for visual testing.

Does my PWA need to support offline to justify specific visual testing?

Even if your PWA doesn't work offline (a "network only" strategy), you need to test what happens when the network is unavailable. The user will see something: a blank page, a browser error, or your fallback page. Whatever it is, that view is part of the user experience and deserves a visual test.

What's the difference between testing a PWA and testing a native mobile app?

Testing a native application requires simulators or physical devices specific to each platform (iOS Simulator, Android Emulator). PWA testing can be largely done with desktop browsers configured at the right viewports, making it more accessible and faster. However, certain aspects (splash screen, safe areas, standalone behavior on iOS) require verification on real or near-real environments.

How do you test the splash screen without a physical device?

You can't test the real splash screen without a device or emulator, because it's generated by the browser at PWA launch. However, you can test its components: visually verify that the manifest icons are correct at all required sizes, that the background color is consistent, and that the apple-touch-startup-image assets (for iOS) are present and of good quality.

Are PWAs still relevant in 2026 with app stores?

Absolutely. According to a web.dev (Google) study, PWAs deliver conversion rates 36% higher than standard mobile websites, primarily thanks to loading speed and offline experience. With the continuous improvement of PWA support on iOS and the European Union's opening to third-party browsers on iPhone (Digital Markets Act), PWAs are more relevant than ever in 2026.