PWA Behavior in Android Chrome
PWA behavior in Android Chrome isn't just tap-and-it-installs — it's a sequence of technical criteria and engagement heuristics worth understanding before you send traffic. Some install problems buyers blame on a weak creative are actually technical, anywhere from the manifest to the domain's certificate. Here's what happens under the hood and what actually moves the needle.
Baseline criteria for the install prompt to appear
Chrome only offers to install a PWA once technical conditions are met: the site runs on HTTPS, the manifest has the required fields (name, correctly sized icons, start_url, a standalone-style display mode), and a service worker is registered and handles fetch. Miss any one of those and the install banner simply won't show, regardless of traffic quality. That's the first thing to check when install conversion suddenly drops.
Engagement heuristics, not an instant banner
Chrome doesn't offer to install from the first second of a visit — the user needs to show some real engagement first, not just open and immediately close the page. That protects users from pushy install prompts on sites they landed on by accident, but it also means high-bounce traffic may never see an install prompt at all. Optimizing the first screen for attention directly affects install rate, not just some abstract engagement score.
The mini-infobar, and running your own prompt via beforeinstallprompt
By default Chrome shows its own compact prompt (the mini-infobar), but the beforeinstallprompt event can be captured in code and replaced with a custom install call-to-action — your own copy, timing, and design instead of the system look. That hands you control over timing — for instance, prompting install only after a user has been through the pre-lander and warmed up, instead of at a random moment. This is exactly where teams that leave the default system behavior in place tend to leave conversion on the table.
WebAPK: how a PWA becomes almost a native app
Once installed, Chrome on Android wraps the PWA into a WebAPK — a package signed by Google that makes the app show up in the app list, settings, and task switcher like an ordinary native app rather than a browser shortcut. That builds user trust and cuts accidental uninstalls of what would otherwise look like some unclear browser bookmark. For a team, it also means manifest updates roll out through Chrome's periodic checks rather than instantly.
What actually breaks install in practice
Install problems are usually technical, not creative: an expired or misconfigured SSL certificate, a manifest error, a service worker that fails registration, or a domain that's been flagged. Own domains with automatic HTTPS and one-click rotation (as in APEX) close off exactly this category of problem — certificates don't quietly expire, and swapping a domain doesn't mean rebuilding the PWA from scratch. Before blaming the creative for a low install rate, it's worth ruling out these technical causes first.
FAQ
- Why doesn't the install banner show for some users?
- A few reasons: technical criteria aren't met (HTTPS, manifest, service worker), the user hasn't shown enough engagement yet, or the prompt was already dismissed once for that site.
- What is a WebAPK?
- It's a Google-signed package Chrome wraps an installed PWA in on Android, which makes it behave in the system like an ordinary native app instead of a browser shortcut.
- Can I show my own Install button instead of the system banner?
- Yes, the beforeinstallprompt event can be captured and deferred, so you can trigger your own install call-to-action at the right moment in the funnel.
- How does the domain affect PWA install in Chrome?
- Install requires stable HTTPS, so certificate problems or careless domain rotation can break both new installs and already-installed PWAs.
Cloaking, anti-bot, push, split tests and your own domains — in one service.
Get started free