Resource
Browser support
PWA UI targets current stable Chromium, Safari, and Firefox releases. Platform-specific capabilities degrade honestly when a browser does not expose them.
Beta support matrix
| Capability | Desktop Chromium | Android Chrome | iOS Safari | Firefox |
|---|---|---|---|---|
| Core layout and navigation | Targeted | Targeted | Targeted | Targeted |
| BottomSheet and dialogs | Targeted | Targeted | Targeted | Targeted |
| Visual viewport handling | Full | Full | Full | Fallback |
| Native install prompt | Available | Available | Manual flow | Unavailable |
| Standalone display mode | Full | Full | Full | Varies |
What degradation means
- Safe-area values resolve to zero on surfaces without display cutouts.
- Viewport-aware layouts fall back to the layout viewport when Visual Viewport is unavailable.
- The install hook reports unavailable when the browser does not offer a programmatic prompt. iOS requires product-specific Share → Add to Home Screen instructions.
- Network status is a browser hint; applications must still handle failed requests.
Application viewport
Start from this viewport, which enables safe-area insets on edge-to-edge and installed surfaces:
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">The remaining choice is Android's interactive-widget policy, and it is a genuine tradeoff rather than a recommendation we can make for you. PWA UI derives keyboard height from the visual viewport shrinking, so the policy decides whether the keyboard hooks can see the keyboard at all.
overlays-content — stable layout, no keyboard detection
The keyboard is drawn over the page and neither viewport resizes. Fixed chrome never moves, which is the most predictable choice for layouts that do not react to the keyboard. In exchange, useVisualViewport reports keyboardHeight: 0, --pwa-keyboard-height stays at 0, data-pwa-keyboard-open is never set, and KeyboardAvoidingView and AppShell.Footer keyboardBehavior do nothing on Android.
resizes-content or the default resizes-visual — keyboard detection works
The viewport shrinks when the keyboard opens, so useVisualViewport, KeyboardAvoidingView, and keyboard-aware chrome respond as documented. With resizes-content the layout viewport resizes too, so fixed chrome reflows with it; with the default resizes-visual only the visual viewport changes.
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover, interactive-widget=resizes-content">iOS Safari ignores interactive-widget entirely and always shrinks the visual viewport, so the keyboard hooks work there whichever policy you set. Choose the policy on your Android layout's behalf, then verify it against your own fixed chrome and forms on a real device.