Key Takeaways
- No browser on iPhone can send push notifications until the site has been added to the Home Screen as a Progressive Web App — this applies equally to Safari, Chrome, Firefox, and every other browser available on iOS.
- The reason every browser is bound by the same rule is structural: Apple requires every browser on iOS to use its WebKit engine under the hood, so Chrome on an iPhone is not running Chrome’s own engine the way it does on a desktop or Android device.
- Even more specifically, the “Add to Home Screen” action that creates an installable PWA can only be triggered from Safari’s own share menu — Chrome and other iOS browsers cannot surface that installation step at all, regardless of how capable their rendering engine is.
- This means a visitor browsing in Chrome on an iPhone has no path to enabling push notifications without first being directed to open the same page in Safari.
- Apple added web push support to Safari in iOS 16.4 (March 2023), roughly eight years after Android gained the same capability — and by early 2026, more than 95% of iPhones in active use run iOS 16 or later, meaning the install flow, not the underlying technology, is now the only real friction point.
If you’ve built a WordPress site with push notifications and noticed that subscribers on iPhone never seem to get prompted no matter which browser they’re using, you’ve run into one of the more confusing platform restrictions in mobile web development. The common assumption is that Chrome on iPhone simply doesn’t support push notifications the way it does on Android. That’s true, but it understates the actual rule — and understanding the real rule changes what you need to build to work around it.
The Rule Applies to Every Browser, Not Just Chrome
The accurate version of the restriction is broader than “Chrome can’t do push on iOS.” No browser on iPhone — Safari included — can send push notifications to an open browser tab. Push notifications on iOS are exclusively available to sites that have already been installed to the Home Screen as a Progressive Web App. A visitor scrolling your site in a normal Safari tab has exactly the same lack of access to push as a visitor in Chrome, Firefox, or Edge on the same device. The install step isn’t a Chrome limitation being worked around by Safari. It’s a universal gate every browser on iOS has to pass through first.
2023
8 years
95%+
Why Every iOS Browser Is Bound by the Same Rule
The reason this restriction applies universally rather than varying by browser comes down to a single Apple platform policy: every browser on iOS, regardless of brand, is required to run on Apple’s WebKit rendering engine. Chrome on an iPhone is not running Google’s Blink engine the way Chrome does on a desktop computer or an Android phone — it’s a Chrome interface wrapped around the same WebKit engine that powers Safari. Independent analysis of PWA capability on iOS states this directly: Chrome, Firefox, Edge, and Brave are all running WebKit under the hood on iPhone, which means PWA and push capabilities on iOS are entirely determined by what Apple’s own WebKit team chooses to support — not by what any individual browser maker builds.
This is why the rule can’t be a Chrome-specific bug or a Firefox-specific oversight. If WebKit doesn’t expose push notification access to an open browser tab, no browser running on iOS has access to it, because no browser on iOS is running anything other than WebKit underneath its own interface.
A Detail Most Developers MissEven after Apple opened up third-party browser engines in the EU under the Digital Markets Act, developer discussion confirms that zero browsers had actually adopted Apple’s BrowserEngineKit as of early 2026 — the friction of implementing it outweighed the benefit. Outside the EU, the requirement to use WebKit remains in force entirely. Practically speaking, “every browser on iOS uses WebKit” is still an accurate, current statement for the overwhelming majority of iPhone users.
The Part That Actually Blocks Chrome Specifically
Here’s where the Chrome-specific friction genuinely does enter the picture — not in whether push works once installed, but in how a visitor gets to the installed state in the first place. Documentation on iOS web push setup lays out the required installation flow explicitly: a visitor has to open Safari, tap the Share icon, scroll to find Add to Home Screen, and tap it. That sequence is tied specifically to Safari’s interface — it isn’t an API any webpage can trigger programmatically, and it isn’t a button that Chrome, Firefox, or any other iOS browser can surface from inside their own interface, because the “Add to Home Screen” action lives in Safari’s native Share sheet, not in the shared WebKit engine underneath.
The practical result: a visitor who lands on your site through Chrome on an iPhone has no install button to tap, no prompt to dismiss, and no path forward from inside Chrome itself. The only way for that visitor to ever receive a push notification is to leave Chrome, open the same URL in Safari, and complete the Add to Home Screen flow there — a hop most visitors will never make on their own unless a site explicitly tells them to.
| Scenario | Can Receive Push? | Why |
|---|---|---|
| Safari, open tab | No | Push only works for installed PWAs — an open tab doesn’t qualify, even in Safari. |
| Chrome, open tab | No | Same WebKit restriction as Safari — plus no install path exists inside Chrome at all. |
| Site installed via Safari → Home Screen | Yes | This is the only state on iOS where push notifications are available. |
| Same site opened from Chrome’s icon (no install) | No | Chrome cannot create a Home Screen PWA — only Safari’s Share sheet can. |
Why Apple Built It This Way
The eight-year gap between Android’s web push support and Apple’s is worth understanding honestly, because it shapes how seriously to treat the restriction going forward. Technical analysis of the timeline describes the delay as business-related rather than purely technical: a fully capable PWA with push notifications reduces the incentive for a developer to publish a native app through the App Store, where Apple collects a 15–30% commission on in-app purchases. Officially, Apple cited privacy and user experience considerations for the delay. The same analysis points out that macOS Safari had supported web push since 2013 — a decade before iOS gained the same capability — suggesting the technical building blocks existed well before Apple chose to ship them on iPhone.
The EU PWA Scare — Resolved, Not OngoingIn early 2024, Apple briefly removed standalone PWA support for users in the European Union during the iOS 17.4 beta, under pressure from the Digital Markets Act — Home Screen web apps in the EU opened as regular Safari tabs instead of installed apps, with no push access. After significant backlash from developers and the European Commission, Apple reversed the decision within about three weeks and restored full PWA support. As of 2026, the install-then-push flow described in this article applies the same way in the EU as everywhere else — the brief removal is a resolved historical episode, not a current limitation.
What This Means for the Install Flow Most Sites Need
Given that the install step has to happen in Safari specifically, regardless of which browser a visitor originally arrived in, the practical fix isn’t trying to make push work inside Chrome — that’s not possible on the current platform. The fix is detecting that a visitor is on an iOS device using a non-Safari browser and routing them toward Safari, where the install flow can actually proceed.
- 1
Detect the browser and platform, not just the device. An iPhone visitor in Safari can be shown the standard Add to Home Screen walkthrough directly. The same visitor in Chrome needs a different message entirely.
- 2
For non-Safari iOS browsers, prompt a copy-the-URL nudge. Since Chrome can’t trigger the install flow itself, the most reliable fallback is guiding the visitor to copy the current page’s address and reopen it in Safari, where the install option actually exists.
- 3
Show the install action only after a visitor opens the link in Safari. Once they’ve made that switch, the standard Share icon → Add to Home Screen walkthrough applies exactly as it would for anyone who arrived in Safari originally.
- 4
Don’t bother building separate logic for Firefox, Edge, or other iOS browsers. Since they all share the same WebKit limitation as Chrome, the same copy-URL-to-Safari fallback covers every non-Safari browser on iOS — there’s no meaningful difference in capability between them.
The real question was never “does Chrome support push on iPhone.” It’s “can any browser other than Safari even offer the one button that makes push possible” — and on iOS today, the answer is no.
This is exactly the gap WhoKnew Signal™’s install shortcode is built to handle. Rather than treating iOS as a single case, the shortcode detects whether a visitor is on iOS specifically and whether they’re already inside Safari or a different browser — Chrome on iOS gets a copy-URL nudge directing them to reopen the page in Safari, while a visitor already in Safari sees the standard guided walkthrough through the Add to Home Screen steps. Neither path requires the visitor to understand WebKit, browser engines, or why the install button isn’t where they expected it to be.
Further Reading
- What Is a Progressive Web App (PWA) for WordPress — the foundational explainer on what makes a site installable in the first place.
- How WordPress Push Notifications Actually Reach a Phone — the three-stop delivery path every push notification travels, regardless of platform.
- What Is VAPID and Why It Matters for WordPress Site Owners — the open standard underlying the push notification mechanism itself.
Who knew the missing install button in Chrome on an iPhone was never a Chrome problem at all — it was a Safari-shaped door that only Safari was ever allowed to open.
