How web push works
Web push runs through a service worker and the browser's push service. The user grants permission, the browser hands your app a subscription token, and your server sends messages to that token — even while the app is closed. The service worker wakes up and shows the notification.
It's the same re-engagement channel native apps use, delivered without an app store. You control the message, the timing, and the deep link that opens when someone taps.
- Triggered from your server, delivered while the app is closed
- Users explicitly opt in — permission is per-site and revocable
- Tap actions can deep-link straight into a specific screen
- No app store required to send or receive them
- Works with segmentation, so you can send to the right users, not everyone
The iOS and Android reality
This is where honesty saves you a nasty surprise. On Android, web push in Chrome is mature and works much like native. On iOS, Apple added web push in Safari 16.4 — but only for web apps the user has installed to the home screen, not for sites open in a normal Safari tab.
That single requirement shapes your whole strategy: on iPhone and iPad, a user must add your PWA to their home screen before they can receive any push at all. We design the install prompt and messaging around that so you don't lose reach.
- Android/Chrome: robust web push, close to native behavior
- iOS/iPadOS: push works only after the user installs the PWA to the home screen
- iOS requires a recent OS version (16.4 or later) for web push at all
- No push on iOS for sites left in a regular Safari tab
- Permission prompts should be earned with context, not fired on first load
When web push is the right call
Web push shines for time-sensitive, opt-in nudges: an order shipped, a price dropped, an appointment tomorrow, a message waiting. It's a strong fit when your audience is Android-heavy or when your iOS users are motivated enough to install.
If your entire model depends on reaching cold iOS visitors who won't install, we'll tell you that up front and suggest email or SMS as the primary channel instead. Book a free consultation and we'll map the right mix for your audience.
- Great for transactional and re-engagement messages users asked for
- Strong on Android; effective on iOS once users install
- Pair with email/SMS to cover users who won't opt in
- Respect frequency — over-sending gets your notifications muted
- Measure opt-in rate and open rate, then tune the strategy
More on progressive web apps
Frequently asked questions
Can I send push notifications to iPhone users with a PWA?
Yes, but only after they install your PWA to their home screen and are on iOS 16.4 or later. Apple does not allow web push to iPhones from a normal Safari tab. We build the install experience so iOS users understand why to add it before you rely on push for them.
Do users have to allow notifications?
Always. Browsers require explicit opt-in, and it's revocable at any time. The best results come from asking at the right moment — after a purchase or an action — rather than the instant someone lands, which usually gets declined.
How is this different from native app notifications?
The core experience is similar, and on Android the gap is small. The main differences are the iOS install requirement and a few advanced native capabilities (like rich background scheduling) that the web handles more simply. For most re-engagement use cases, web push does the job without a store.