Mobile web push is the delivery of system-level notifications from a website or progressive web app (PWA) to a smartphone or tablet through the browser, without a native app. In the mobile web it relies on three web standards working together: the Push API, the Notifications API and a service worker that wakes up in the background to receive messages and display them, even when the site is not open.
On Android, mobile web push has worked in Chrome and other browsers for years. On iPhone and iPad, Safari supports it from iOS 16.4 onward, but only for web apps the user has added to the home screen. This difference shapes how teams design notification strategies for the mobile web.
How mobile web push works
Mobile web push follows a subscription and delivery chain. The site registers a service worker, asks for notification permission after a user gesture, and creates a push subscription through the browser. The subscription contains an endpoint URL at the browser vendor’s push service and encryption keys unique to that user and device.
To send a message, the site’s server encrypts the payload, signs the request with its VAPID keys to prove its identity, and posts it to the endpoint. The push service delivers it to the device, where the operating system wakes the browser and the service worker’s push event shows the notification. Payloads are limited to about 4 KB, so messages usually carry a title, text and a link rather than content.
| Component | Where it runs | Role |
|---|---|---|
| Service worker | Browser on the device | Receives push events, shows notifications |
| Push API | Browser | Creates and manages subscriptions |
| Notifications API | Browser and operating system | Displays and handles notification clicks |
| Push service | Browser vendor infrastructure | Queues and delivers encrypted messages |
| Application server | Site operator | Stores subscriptions, encrypts and sends messages |
Platform support and requirements
Support for mobile web push is not uniform, and the iOS model differs most. Safari on iOS and iPadOS delivers web push only to a site installed as a home screen web app with a valid web app manifest, and the permission prompt must follow a direct user action such as tapping a button.
| Platform | Requirement | Notes |
|---|---|---|
| Android, Chromium browsers | HTTPS site with service worker | Works in the browser tab and installed PWAs |
| Android, Firefox | HTTPS site with service worker | Uses Mozilla’s push service |
| iOS and iPadOS 16.4 or later | Web app added to home screen | No push for regular Safari tabs |
| In-app browsers | Usually unsupported | Embedded web views lack push |
| All platforms | Secure context and user consent | Permission can be revoked at any time |
Browsers also enforce quiet permission UI for sites with poor acceptance rates, and they may reduce visibility of prompts that appear on page load. A request shown without context is therefore not only bad practice but often technically suppressed.
Mobile web push compared with native and other channels
Mobile web push gives web teams a re-engagement channel without an app store, but it does not match native push in every respect. Native apps use APNs or Firebase Cloud Messaging directly and gain richer features, while email and SMS reach users who never granted notification permission.
| Channel | Install needed | Rich features | Main limitation |
|---|---|---|---|
| Mobile web push | No on Android, home screen on iOS | Title, body, icon, actions | Lower opt-in and feature set |
| Native app push | App from a store | Rich media, categories, critical alerts | Requires app install |
| No | Long content | Slow attention, spam filters | |
| SMS | No | Plain text | Cost per message, strict consent rules |
For many publishers and online shops, mobile web push works best as a complement to email: it is immediate and short-lived, so it suits time-sensitive events like order status, price drops or breaking news.
Implementing mobile web push well
Successful implementations treat permission as something earned through value. The site first explains what notifications will contain, then asks only when the user shows interest, for example after placing an order or following a topic.
- Serve the site over HTTPS and register a service worker with a clear scope.
- Provide a web app manifest so the site can be installed, which iOS requires.
- Ask after a meaningful action, using an in-page explanation before the browser prompt.
- Store subscriptions securely and delete them when the push service reports them as expired.
- Offer preferences for topics and frequency, and an easy way to unsubscribe.
Sending should respect frequency limits and time zones. Users who receive irrelevant or excessive notifications revoke permission quickly, and that permission is very hard to regain, because browsers do not let sites ask again once it is blocked.
Limitations and common mistakes
Most failures of mobile web push come from misunderstanding platform rules or from treating notifications as a marketing megaphone.
| Mistake | Consequence | Remedy |
|---|---|---|
| Prompt on first page load | Low opt-in, quiet prompt UI | Ask after user intent is clear |
| Expecting push in iOS Safari tabs | No subscription possible | Guide users to add to home screen |
| Ignoring expired subscriptions | Failed sends, wasted resources | Remove endpoints returning gone status |
| Sensitive data in payloads | Exposure on the lock screen | Send neutral text, show details in app |
| Too many messages | Permission revoked permanently | Set frequency caps and topic choices |
Explained without jargon
Mobile web push lets a website send alerts to your phone, just like an app does. You might get a message that your parcel has shipped or that a news story has broken, even though you never installed an app.
The website must ask first, and you can say no or switch it off later. On iPhones there is one extra step: you add the website to your home screen before it can send alerts. After that, the alerts appear in the same notification list as messages from regular apps.
A typical use case
A regional public transport operator runs a PWA for timetables and disruption alerts, but has no native app. Commuters can follow their usual lines, and after they tap Follow on a line, the site explains that it will send only disruption alerts for that line and then shows the browser permission prompt.
On Android, commuters subscribe directly from the browser. On iPhones, the site first shows short instructions for adding it to the home screen, then offers the same option inside the installed web app. When a line is suspended, the server sends a short alert to subscribers within seconds, and the operator avoids the cost of building and maintaining two separate native apps.