On Android System WebView the Web Share API simply does not exist: navigator.share is undefined. On iOS it exists only behind a user gesture, a secure context, and a feature policy that embedded browsers routinely strip. The page cannot open the OS share sheet, so the share button either errors out or silently falls back to a copy-link. A host-owned runtime exposes a real native share bridge — one sheet, every engine, every embedded browser.
navigator.share is missing, not just unsupported
The Web Share API works in Chrome, Edge, Safari, and Samsung Browser. It does not work in Android System WebView. MDN's browser-compatibility table is explicit: under "WebView Android" the Web Share API is No. A Tauri plugin notes the same blunt fact — "The Web Share API (navigator.share) is not supported in Android WebView, even though it's Chromium-based." So a share button built to the spec does nothing: if (navigator.share) is false, the handler never runs, and the feature is invisible.
iOS is supported but gated hard
On iOS, WKWebView supports Web Share from iOS 14 — but only when every condition holds. The call must sit inside a user-activation handler such as a click; awaiting any fetch or analytics call before share() runs discards the activation and the call rejects with NotAllowedError. It requires a secure context (https — http:// and most file:// origins expose no API at all). Inside an iframe it needs allow="share". And built-in browsers — WeChat, TikTok, Instagram — frequently do not implement the sheet or strip the permission policy, so the same code that works in Safari fails there.
What breaks when the sheet is gone
- The button does nothing. On Android WebView
navigator.shareisundefined; the click is a no-op. - Silent failure. iOS rejects outside a gesture or secure context with
NotAllowedError/AbortErrorthe page is not even told to expect. - Copy-link is the only fallback. Losing the OS share sheet means losing every social target, messenger, and AirDrop — a degraded experience users notice.
- Embedded browsers diverge. WeChat/TikTok/Instagram silently skip the sheet while Safari works, so QA in Safari hides the real-world break.
- File sharing is narrower still.
canShare({ files })returns false on engines that cannot share files at all, forcing yet another branch.
The runtime fix
A host-owned runtime owns the share intent. The host registers a native share bridge and opens the real OS share sheet — UIActivityViewController on iOS, Intent.ACTION_SEND with Intent.createChooser() on Android — carrying title, text, URL, and files across every engine and every embedded browser. The page calls one uniform bridge; the runtime decides how to present it. One share surface, everywhere.
| Dimension | WebView | Host-owned runtime |
|---|---|---|
Android navigator.share | Undefined | Native sheet |
| iOS gesture/secure gate | Easy to miss | Handled natively |
| Embedded browsers (WeChat, etc.) | Sheet stripped | Native sheet |
| File sharing | Narrow, canShare gated | Native sheet + files |
| Fallback | Copy-link only | Real targets |
| Consistency | Per-engine | Uniform |
A native app opens the OS share sheet on every phone. A stock WebView opens it on almost none. A runtime gives the page one sheet — and every target behind it.
Sources
- MDN — Web Share API — the compatibility table that marks "WebView Android: No" for
navigator.share. - web.dev — Web Share API — the user-activation, secure-context, and
canSharerules that gate sharing. - OpenPWA — Web Share API reference — why
NotAllowedError/InvalidStateErrorappear and how to fall back to copy-link. - Apple — Implementing Web Share in WKWebView — the iOS WebView support and the gesture/secure-context constraints.
- Tauri plugin — why Android WebView lacks navigator.share — a maintainer confirms the API is absent in Android System WebView even though it is Chromium-based.
