Why Web Push Notifications Fail on iOS (A Guide for E-Commerce Merchants)

Web push notifications sound like the perfect answer to e-commerce's biggest problem. Shoppers browse and leave without giving you an email or phone number — and web push promises to reach them anyway, straight from the browser, no contact info required. It's the pitch behind every web push tool in the Shopify App Store.

On desktop and Android, the pitch is mostly true. On iPhone — where the majority of US mobile shopping traffic actually lives — it quietly falls apart.

This guide explains exactly why, with the technical receipts: what Apple does and doesn't allow, the install step that kills adoption, the reliability problems underneath, and what merchants can use instead to reach iPhone shoppers who browse and bounce.

The Short Version

Web push on iOS only works if the shopper first installs your website to their Home Screen as a web app — Safari's Share button, then "Add to Home Screen" — and then opens it from that icon and grants notification permission. Apple's own documentation is explicit about this requirement.

Read that sentence again as a shopper, not a developer. Someone tapped your TikTok ad, scrolled two product pages for 40 seconds, and left. At what point in that journey were they going to open the Share sheet and install your store to their Home Screen?

They weren't. And that, in one paragraph, is why web push fails for e-commerce on iOS. Everything below is the supporting detail.

How We Got Here: A Brief History of Apple vs. Web Push

Web push has worked in Chrome and Firefox since around 2015 — a website asks permission, the shopper taps Allow, done. Apple declined to support it on iOS for nearly a decade, citing privacy and user-experience concerns.

That changed in early 2023: iOS 16.4 brought Web Push to iPhone for the first time. Notification vendors announced it as a watershed. The fine print told a different story:

• Push works only for web apps added to the Home Screen. A site open in a Safari tab — or any other browser tab — cannot ask for push permission at all.
• No other browser can fix this. Chrome and Firefox on iOS are required to use Apple's WebKit engine underneath, so they inherit the same restriction. There is no "just use Chrome" workaround.
• The channel exists at Apple's discretion — and Apple has already switched it off once. In early 2024, Apple removed Home Screen web apps for EU users in the iOS 17.4 beta as part of its Digital Markets Act compliance, killing web push there with them. After an outcry from developers, Apple reversed the decision weeks later and kept the capability. It worked out — this time. But a recovery channel that can be deleted by a policy footnote is a channel you rent, not one you own.

So the headline "iOS supports web push" is technically true and practically misleading. It supports web push for the narrow set of users who install websites to their Home Screens.

The Install Wall: Why Almost No Shopper Qualifies

Here's the full sequence an iPhone shopper must complete before you can send them a single web push notification:

1. Visit your store in Safari (not through the Instagram or TikTok in-app browser — those don't support Add to Home Screen prompts in a usable way)
2. Tap the Share icon
3. Scroll the share sheet and tap "Add to Home Screen"
4. Confirm the install
5. Leave Safari, find the new icon on their Home Screen, and open your store from it
6. Encounter your permission prompt and tap Allow

Six steps, spanning two apps, for a store they discovered forty seconds ago. Industry analyses of PWAs on iOS put the reachable push audience at roughly one-tenth to one-fifteenth of what native app push achieves, precisely because of this install wall. And that comparison is against app installers — already a self-selected, high-intent group. Measured against cold ad-click traffic, the share of shoppers who complete a Home Screen install rounds to zero.

Notice the irony: web push is marketed as the channel with no signup friction, and on iOS it has the highest friction of any channel. Getting an email address is one form field. Getting a Home Screen install is a six-step ritual most iPhone owners have never performed for any website in their lives.

It Gets Worse: Reliability After the Install

Suppose a shopper somehow completes the install and grants permission. The infrastructure underneath still isn't built for dependable e-commerce messaging:

Push tokens silently expire. Developers report on Apple's own forums that Safari web push tokens become invalid without any notification to the sender — sometimes within days — with no API to detect the failure. Your dashboard says "sent"; the shopper's phone says nothing. You have no way to know which.

No background recovery. The background mechanisms that native apps use to keep messaging reliable — background sync, silent pushes to refresh state — don't exist for web apps on iOS. When delivery breaks, it stays broken until the shopper voluntarily reopens your web app. Which, for a store they browsed once, is never.

Permission and storage are fragile. Safari aggressively clears storage for sites the user doesn't revisit, and the notification relationship can be lost with it. A subscriber list of one-time visitors decays on its own schedule, not yours.

None of this matters much for the audiences web push genuinely serves — daily-habit websites whose users happily install them. It matters enormously for abandonment recovery, where the entire value is reaching someone after a single visit.

Where Web Push Actually Works (An Honest Accounting)

Web push is not a scam; it's a channel with a shape, and it's only fair to describe where the shape fits:

• Android traffic. Chrome on Android supports web push from the browser with a simple permission prompt — no install wall. If your traffic skews Android, web push is a legitimate recovery layer.
• Desktop traffic. Chrome, Edge, and Firefox on desktop all support browser-level push. For stores with meaningful desktop browsing, it works.
• Habitual audiences. News portals, sports sites, content platforms — audiences that return daily and will install a web app. It's no accident that the flagship case studies of web push vendors are overwhelmingly media companies, not merchants.

The problem is the mismatch between that shape and where e-commerce ad money goes. Paid social traffic from Instagram and TikTok is heavily iPhone-weighted — exactly the segment web push can't reach. A recovery channel that works everywhere except where your customers are isn't a recovery channel; it's a dashboard.

What Works on iOS Instead: Native Push via App Clips

The reason native apps don't face the install wall is that Apple built push notifications for native experiences. The traditional catch was that "native" meant convincing shoppers to download an app — even less realistic than a Home Screen install.

App Clips remove that catch. An App Clip is a lightweight native iOS experience that launches instantly from a link — a shopper taps your ad, and your storefront opens as a native app surface with Apple Pay built in. No App Store, no download, no account. And because an App Clip is a real native context, Apple grants it something no website gets: the ability to send native push notifications for up to 8 hours after the session, with no opt-in form at all.

Compare the two paths for the same abandoning shopper:

• Web push path: shopper must install your site to their Home Screen (they won't), reopen it, and grant permission — before you can send anything.
• App Clip path: shopper taps your ad, browses, leaves. You can already reach their Lock Screen.

Same shopper, same visit, same zero contact information — one channel structurally can't be established, the other is live from the first tap. The notification arrives through the same system channel as iMessage, on the Lock Screen, not filtered into a browser's notification tray.

The honest trade-offs, because this article has been about fine print: App Clips are iOS-only (pair them with web push for your Android segment — the channels are complementary, not rivals), and the no-opt-in window is 8 hours, designed for session recovery rather than long-term broadcasting. For abandonment — a game decided in the first hour — that window is the useful part. We covered why speed dominates abandonment recovery in our browse abandonment guide.

The Bottom Line

Web push on iOS isn't broken because vendors are lying to you — it's broken because Apple only permits it behind an install step that abandonment traffic will never perform, and the vendors' marketing pages simply don't dwell on that. Check any web push tool's case studies and count the merchants versus the media sites.

If your growth runs on paid social and your buyers carry iPhones, the browser was never going to be the channel that brings them back. The native layer — the one Apple actually built notifications for — now has a door that opens from a single ad tap. That's where iOS recovery happens.

For the bigger picture of why abandonment is a browsing problem rather than a checkout problem, start with our cart abandonment thesis.

Want to recover the 93% of shoppers who leave before adding to cart?