Browser & Platform Support

Web push depends on three browser capabilities: a Service Worker, the Push API, and the Notification API. Where these exist, SharePush works; where they don't, the SDK degrades gracefully and never shows a broken prompt.

#Quick matrix

Platform / Browser	Push supported?	Notes
Chrome, Edge (desktop & Android)	✅	Full support, incl. one-tap PWA install.
Firefox (desktop & Android)	✅	Push works; native install prompt not offered (Firefox doesn't fire it).
Safari (macOS)	✅	Supported on modern macOS.
Safari (iOS/iPadOS)	⚠️ Conditional	Requires iOS 16.4+ AND the site installed to the Home Screen. See below.
DuckDuckGo	❌	Blocks push at the engine level. See below.
In-app webviews (Instagram, Facebook, TikTok…)	❌ usually	Push APIs missing/restricted → the SDK shows the in-app bridge.

#iOS / iPadOS — the two requirements

Apple supports web push only under both conditions:

iOS/iPadOS 16.4 or newer. On older versions the SDK detects the unsupported runtime and stays completely silent (no prompt, no error noise).
The site is installed to the Home Screen (added as a PWA). Safari does not allow web push for regular browser tabs on iOS.

This is why the PWA install prompt is essential on iOS — without the install, there's no path to push. The SDK shows iOS-specific "Add to Home Screen" guidance to walk users through it.

#DuckDuckGo — push is blocked by design

The DuckDuckGo browser (and its mobile app) blocks push notification requests at the engine level as part of its privacy/anti-annoyance stance. The permission prompt never appears, and there's no technical workaround. The SDK treats DuckDuckGo as unsupported: it won't show a prompt that can't succeed, and any custom subscribe UI is hidden.

For this audience, push simply isn't a viable channel — consider on-page alternatives (e.g. an email signup). This is expected behavior, not a misconfiguration.

#In-app webviews

Embedded browsers inside social apps typically lack reliable push support. Instead of a dead-end prompt, the SDK shows the in-app bridge inviting the visitor to reopen the page in Safari or Chrome. Disable with inAppBridgeEnabled: false.

#Tablets & desktop-mode caveat

Android tablets in normal mode are correctly detected as mobile. However, a tablet running with "Request desktop site" enabled sends a desktop-class user agent, which the SDK classifies as a desktop environment — so it follows the desktop prompt path rather than the mobile one. For the vast majority of visitors (normal mobile mode) this doesn't apply.

#How "unsupported" is handled

When the environment can't do push, the SDK:

stays silent (no push/PWA prompt), or
shows the in-app bridge if it's an in-app webview and the bridge is enabled.

It never surfaces a prompt that would fail — protecting both your permission request and the visitor's experience.

#Standalone / already-installed detection

If the site is already running as an installed app (standalone display mode, iOS navigator.standalone, or a TWA), the SDK recognizes it and skips the install prompt accordingly.

Next: Troubleshooting & FAQ →