A progressive web app relies on the Web Push API and a Service Worker to re-engage users — cart reminders, breaking news, ride alerts, two-factor codes. That pipeline is exactly what does not exist inside a WebView. Android WebView has no Push API and no background execution; Apple's own DTS engineers state plainly that Web Push will not work in any app that uses WKWebView. The permission prompt never appears, the subscription silently fails, and every re-engagement message the H5 was built to send disappears. A host-owned runtime restores the channel with a native push bridge: FCM or APNs on the device, a JS bridge to register the token, and one handoff that looks exactly like the web standard to the page.
Android: no Push API, no background wake-up
The Android docs and the ecosystem agree: WebView is a rendering component, not a full browser. It does not implement the Push API, it does not keep a Service Worker alive for push, and when the app is closed it cannot wake to receive anything. Developers who try to "club web push with the WebView" conclude it is not possible with the WebView alone; the workaround is to drop down to Firebase Cloud Messaging on the native side and push the payload across a JavaScript bridge. That is real work — a messaging service, a notification channel, a token-sync flow — that a stock WebView simply does not offer.
iOS: the platform says no
On iOS the situation is sharper. A WebView page can register a Service Worker in some configurations (with app-bound domains or a browser entitlement), but Web Push itself is unavailable. In Apple's developer forums an Apple DTS engineer answers the question directly: "Web Push Notifications will not work in apps with a WKWebView. You can use native push notifications with an app that also happens to have a WKWebView, but not Web Push." The same page that shows a clean subscribe button in Safari shows nothing in the embedded view — no prompt, no error, just silence.
What you lose without a push channel
- Dead subscribe buttons. The prompt never appears, so users who would have opted in simply never do.
- Lost re-engagement. Abandoned-cart nudges, delivery updates, and news alerts — the entire reason PWAs invest in push — never arrive.
- Fragmented identity. A user logged into the H5 in a system browser is a stranger inside the app's WebView, and push cannot bridge that gap either.
- Silent divergence. The same code subscribes fine in Chrome and Safari and silently no-ops in the WebView.
- No background sync. Service-worker-driven background sync and periodic fetches are unavailable, so offline write-behind queues stall.
The runtime fix
A host-owned runtime ships a native push bridge below the page. It registers the device with FCM or APNs, exposes a tiny JS API (request permission, get token, receive payload) that mirrors the web's Push API, and routes notifications to the right in-app route on tap. The H5 author writes the same subscribe flow; the runtime supplies the channel the WebView lacks, on both platforms, with one consistent contract.
| Dimension | WebView | Host-owned runtime |
|---|---|---|
| Push API | Not implemented | Native bridge (FCM/APNs) |
| Permission prompt | Never shown | Native prompt, mirrored to JS |
| Background wake-up | Impossible when app closed | OS-level delivery |
| Service Worker push | Unsupported | Bridged to native |
| Re-engagement | Lost | Restored |
| Cross-platform contract | None | One API, both OS |
A browser treats a subscribe button as a promise of a future message. A stock WebView treats it as a request it is free to ignore. A runtime keeps the promise — one push channel, native on the device, web-shaped to the page.
Sources
- Apple Developer Forums — Web Push will not work in apps with a WKWebView (DTS engineer) — the platform-level confirmation.
- Stack Overflow — WebView does not support the Push API on Android — the missing API.
- MDN — Push API reference — the web standard the WebView lacks.
- web.dev — Push notifications overview — how the pipeline is supposed to work.
- MDN — Service Worker API — the background script WebView cannot keep alive for push.
