PWA testing: install, offline and push checklist

A progressive web app is a website until the moment it is installed, and that moment is where most PWA bugs appear: a manifest that fails silently, a service worker that serves a stale version forever, or a standalone window with no way back. This guide lists what to test in a PWA on Android, desktop Chrome and iOS Safari, and gives you a task your AI beta tester can run in the browser.

Who it’s for

  • Web teams adding a manifest and service worker to an existing app
  • Startups shipping a PWA instead of native apps
  • Developers debugging install or offline problems reported by users
  • Teams preparing a PWA for a Lighthouse or store-wrapper review

Updated 2026-10-25.

What PWA testing covers

PWA testing checks the three things that turn a website into an app: it can be installed from the browser, it keeps working offline or on a bad connection, and it stays up to date through its service worker. Push notifications, standalone-mode navigation and the manifest details round it out. Because the installed app and the browser tab share the same code, a PWA beta is mostly a web beta plus a specific checklist, and most of it can be run in a browser.

Install

  • Android and desktop Chrome / Edge: the browser fires beforeinstallprompt when the site is served over HTTPS, has a valid manifest and a service worker with a fetch handler. Test that your custom install button appears only when the event fired, that the prompt works, that the icon and name on the home screen or taskbar are right, and that a second visit does not keep nagging after a dismissal.
  • iOS Safari: there is no beforeinstallprompt. Users install through Share, then Add to Home Screen. Test that your instructions for iOS are shown only on iOS Safari, that the home screen icon uses your apple-touch-icon, and that the app opens in standalone mode with the right status bar style. iOS also evicts storage for web apps that have not been used for a while, so test what happens when local data is gone.
  • After install, open the app from the home screen or desktop and confirm it starts at start_url, not at the page the user was on when they installed.

Manifest

  • name and short_name fit under the icon; short_name is what shows on most home screens.
  • Icons at the required sizes plus a maskable icon so Android does not pad or crop your logo in a white circle.
  • display: standalone (or minimal-ui) and theme_color match the app; background_color makes the splash screen look intentional.
  • start_url and scope are correct, especially for apps served under a path.
  • Screenshots and description if you use richer install dialogs.

Service worker and offline

  • The app shell loads with the network off. Go offline in the browser, reload, and check every main route.
  • Pages or data that cannot work offline show a clear offline state or a custom offline page, never the browser's dinosaur.
  • Writes made offline (forms, drafts) are either queued and synced or clearly refused; nothing is silently lost.
  • Cached API responses do not show one user's data to another after logout.
  • Cache storage does not grow without limit; old caches are deleted on activation.

Updates

This is where most long-lived PWA bugs live. Deploy a visible change and check:

  • The new service worker installs on the next visit and takes over according to your strategy: on next launch, or immediately with skipWaiting and a "new version available, reload" prompt.
  • Users are never stuck on a stale version for days because the old worker keeps serving cached HTML.
  • Hashed assets and the HTML shell are versioned together, so a new shell never requests assets the old cache does not have.
  • An update while the app is open in two tabs does not break either one.

Standalone mode

Installed PWAs have no browser chrome, which breaks assumptions:

  • There is a way back from every screen. Standalone iOS has no back button at all; Android has the system back gesture.
  • External links open in the browser (or an in-app browser), not in the standalone window with no address bar and no way back.
  • Links to your own domain stay inside the app; links outside scope do not strand the user.
  • The status bar, notch and home indicator do not cover content; viewport-fit=cover plus safe-area insets if you use them.
  • Login flows that redirect to a third party (OAuth, payment pages) return to the app, not to a new browser tab that leaves the standalone app logged out.

Push notifications

  • Web Push works on Android Chrome and desktop browsers after permission. On iOS, Web Push is available from iOS 16.4 only for web apps installed to the home screen, and permission must be requested from a user gesture.
  • Ask for notification permission in context after the user has a reason, not on first load.
  • Tapping a notification opens the right page in the installed app, not a new browser tab.
  • Unsubscribing and re-subscribing works, and the server stops sending after unsubscribe.

Lighthouse and tooling

Run Lighthouse in Chrome DevTools or from the command line for the installability checks and the performance, accessibility and best-practice audits, and use the Application panel in DevTools to inspect the manifest, service worker state and cache storage. These catch configuration mistakes; the checklist above catches behavior.

Example PWA bug report

Title: Installed app stuck on old version; "Reload to update" never appears
Environment: Android 14, Chrome 129, PWA installed from the home screen;
also on desktop Chrome 129 (Windows 11)
Severity: High (users keep seeing a broken checkout we fixed a week ago)

Steps to reproduce:
1. Install the app and use it once.
2. Deploy a new release (or wait for one).
3. Open the installed app, use it, close it, reopen it twice.

Expected: The new version is active by the second launch, or a "new version
available" prompt is shown.
Actual: The app keeps serving the old HTML. DevTools shows the new service
worker in "waiting" indefinitely. Only clearing site data updates it.

Evidence: screenshot of Application > Service Workers, recording of the
stale checkout screen.
Notes: skipWaiting is never called and no update prompt is implemented.

Common PWA bugs

  1. No install prompt because the manifest has an invalid icon or the service worker lacks a fetch handler.
  2. Users stuck on a stale version after a deploy.
  3. Blank screen offline because an API call blocks rendering.
  4. External links trapped in the standalone window.
  5. OAuth redirect opens the browser and leaves the installed app logged out.
  6. Icon cropped or padded on Android because there is no maskable icon.

Mistakes to avoid

  • Testing only in a browser tab and never installing the app.
  • Not testing on iOS Safari, where install, storage and push behave differently.
  • Caching HTML aggressively with no update strategy.
  • Requesting push permission on first load.
  • Serving the PWA over a URL with mixed content or redirects that break the service worker scope.

Manual testing vs an AI beta tester for PWAs

Real users on their phones catch what a browser pass cannot: push notifications arriving over days, background sync on flaky mobile networks, storage eviction on iOS after weeks of disuse, and whether the installed app earns a place on the home screen.

An AI beta tester like betatest.ing covers the repeatable part in a real browser, on desktop and mobile viewports: it checks the manifest and the install prompt, goes offline and reloads every main route, deploys-and-reloads to see whether the update is picked up, follows internal and external links, checks safe areas and forms, and files bug reports with steps to reproduce, severity, annotated screenshots and recordings. Re-run it after every deploy to catch stale-cache regressions early. It does not verify push delivery to real devices or iOS home-screen installs, so keep a few real phones for those. Test logins are encrypted and never shown to the AI.

The test task

What you send your AI beta tester. It works out the steps and tests like a real user.

Test my PWA at [URL] as an installable web app in the browser, on a desktop and a mobile viewport. It is [WHAT THE APP DOES]. Check the web app manifest (name, short name, icons including a maskable icon, start URL, display mode, theme color) and whether the browser offers to install it; note if the install prompt is missing and why, if visible. Sign in with the saved test login if needed, then visit every main screen. Go offline and reload each one: note which work, which show a proper offline message, and which show a blank page or browser error. Try submitting a form offline and check nothing is silently lost. Come back online, reload, and check the app updates to the latest version instead of serving stale content. Follow internal and external links and confirm the user can always get back. Check that the notification permission is not requested on first load. Do not make any purchases. Log each bug as a finding with steps to reproduce and an annotated screenshot, record any flow that breaks, and end with a report that scores installability, offline behavior, update handling and navigation with the top fixes.

Fill in your details

Here, or later in the chat with your tester.

  • [URL] The HTTPS address of your PWA
  • [WHAT THE APP DOES] One sentence about the app and its users

What the AI beta tester checks

  • Web app manifest fields and icons
  • Install prompt availability in the browser
  • Service worker registration and offline load of every main route
  • Offline states and form handling without a connection
  • Update to a new version after a deploy
  • Internal and external link behavior
  • Login and redirect flows returning to the app
  • Notification permission timing
  • Layout on desktop and mobile viewports

What you get

  • Findings with steps to reproduce and the browser used
  • Annotated screenshots of install, offline and update issues
  • Recordings of flows that break offline or after an update
  • A report with scores for installability, offline, updates and navigation plus the top fixes

How to run it with betatest.ing

  1. Add your PWA's URL as a project in betatest.ing and add a test login if it needs an account.
  2. Send the PWA testing task; the tester runs it in a real browser on desktop and mobile viewports.
  3. Fix manifest, service worker and navigation findings, deploy, and ask for a re-test to confirm the update is picked up.
  4. Hand a few real phones, including an iPhone, to human testers for install, push and long-term storage checks.

Tips

  • Install the app on at least one Android phone and one iPhone before every release; a browser tab hides most PWA bugs.
  • Decide on an update strategy (prompt to reload or update on next launch) and test it on every deploy.
  • Add a maskable icon so Android does not crop your logo.
  • Never request push permission on first load; ask after the user has a reason to say yes.

PWA testing: FAQ

Why does my PWA not show an install prompt?

Chrome requires HTTPS, a manifest with a name, icons at the required sizes, a start URL and a standalone or minimal-ui display mode, plus a registered service worker with a fetch handler. The Application panel in DevTools and Lighthouse list what is missing. iOS Safari never shows a prompt; users install through Share, then Add to Home Screen.

Can a PWA be installed on iPhone?

Yes, through Safari's Share menu with Add to Home Screen. There is no automatic prompt, some web APIs are limited, storage can be evicted after a period of disuse, and Web Push works only for installed home-screen web apps on iOS 16.4 and later.

How do I test offline mode in a PWA?

Install the app or open it in the browser, let the service worker finish installing, then switch the network off (DevTools has an Offline option) and reload every main route. Check for a proper offline state, no blank pages, and that offline writes are queued or clearly refused.

Why do users see an old version of my PWA after I deploy?

A new service worker installs but waits until all tabs of the old one are closed, and the old one keeps serving cached HTML. Either call skipWaiting and show a reload prompt, or make sure the update activates on next launch, and version your HTML shell together with your assets.

Can an AI beta tester test my PWA?

Yes, in a real browser on desktop and mobile viewports: manifest, install prompt, offline reloads, update behavior, navigation, forms and layout, with bug reports, screenshots and recordings. It does not verify push delivery to real devices or iOS home-screen installs, so use real phones for those.

Do PWAs support push notifications?

Web Push works on Android Chrome and desktop browsers, and on iOS 16.4 and later for web apps added to the home screen. Request permission from a user gesture and in context, and test that tapping a notification opens the right page in the installed app.

Can I put a PWA in the app stores?

Google Play accepts PWAs packaged as a Trusted Web Activity, and there are wrappers for other stores. The store listing and policy checks then apply as for any app, so run the store readiness checks as well.

How do I check my PWA against Lighthouse?

Open Chrome DevTools, choose Lighthouse and run the audits on the deployed HTTPS URL. Fix the installability and best-practice failures first, then use the checklist on this page for the behavior Lighthouse does not test.

Related beta testing guides

  • Web app beta testing — Web apps fail in ways websites do not: lost state, stale data, broken sessions and actions that half-complete. This guide shows what to test in an interactive web app before real users depend on it, and gives you a task to hand to your AI beta tester.
  • Mobile app beta testing — Mobile apps reach testers through store testing tracks, run on hardware you do not control, and get interrupted constantly. This guide covers how to distribute a mobile beta, what to test that is specific to phones, and how an AI beta tester fits alongside your human testers.
  • Website performance check — A slow page loses visitors before they see anything. This page explains the Core Web Vitals thresholds, what a browser-based performance check can tell you, and a test task your AI beta tester can run on your key pages.
  • Responsive design testing — Most layouts are designed on a wide screen and break quietly on a phone. This page explains which widths to test, the layout bugs that come up again and again, and a task your AI beta tester can run at phone and tablet sizes.
  • Cross-device testing — Your product will be used on phones, tablets and laptops of every size, in different browsers. This page helps you choose a sensible device mix, lists what typically breaks between devices, and gives you a task for your AI beta tester.
  • Free tool: Beta testing checklist generator — An interactive checklist for websites, SaaS, mobile apps, stores and extensions. Progress saved, Markdown export.

More in by product