--- title: Can I Send Push Notifications From My Pwa? description: PWA push notifications now work on Android and iOS. Learn how service workers, VAPID keys, permission prompts and backend choices fit together. image: https://weareaffective.com/hubfs/learning-centre-images/can-i-send-push-notifications-from-my-pwa.webp --- [Skip to content](https://weareaffective.com/learning-centre/can-i-send-push-notifications-from-my-pwa#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # Can I Send Push Notifications From My Pwa? Table of Contents Apple shipped web push for Home Screen web apps in iOS 16.4, back in March 2023. Before that, the honest answer to "can I send push notifications from a PWA" was yes on Android and no on iPhone, which ended the conversation for any product with an iPhone-heavy audience. PWA push notifications now work across every major platform, with a different set of conditions attached to each one. > iPhone users have to add your web app to the Home Screen before a single push gets through. The conditions are the whole story. On Android and desktop, a person visiting your site in Chrome can grant permission and start receiving pushes without installing anything at all. On iPhone, they have to save your web app to the Home Screen first, and most people never do that on their own. So this piece covers the technical side properly, including service workers, the Push API, VAPID keys and the [build steps to add push notifications](https://weareaffective.com/app-architecture) to a PWA. It also covers the part that decides whether any of it works, which is what you send, when you send it, and how you ask. We've built notification systems where the timing was worked out from focus groups rather than guessed, and that work is where the real difference sits. ## The Short Answer: What PWAs Can and Cannot Do Yes, you can send push notifications from a PWA. On Android, Windows, macOS, Linux and ChromeOS, the browser handles it directly. Chrome, Edge, Firefox, Opera and Samsung Internet all support the Push API. The person grants permission, your server sends a message, and the notification appears even when the browser is closed. On iPhone and iPad, the same code works, with one gate in front of it. Safari only hands out push permission to a web app that's been added to the Home Screen. Running your site in a Safari tab gets you nothing. #### What PWA push notifications do well Title, body, icon, badge, a URL to open on tap, and grouping by tag. On Android and desktop you also get action buttons, large images and vibration patterns. That covers the vast majority of what a retention push actually needs to do. #### The real limits - Silent background pushes are blocked. Chrome makes you show a notification for every message you send. - Scheduled local notifications aren't available, so every push has to come from your server. - iOS Safari strips out action buttons and images. - Deleting the Home Screen app on iOS wipes the subscription completely. - Permission denied once in the browser is very hard to recover. ## How Web Push Actually Works: Service Workers, the Push API and VAPID Keys Three pieces do the work. A service worker is a small JavaScript file that the browser keeps alive separately from your pages, so it can wake up and show a notification when your site isn't open. The Push API is how that service worker registers for messages. VAPID keys are how the push service knows the message really came from you. The push service sits in the middle and belongs to the browser vendor. [Chrome uses Firebase Cloud Messaging](https://weareaffective.com/learning-centre/what-happens-if-apple-or-google-changes-their-push-notification-rules), Firefox uses Mozilla's autopush, and Safari uses Apple's own service. You never pick one. When a user subscribes, the browser hands you an endpoint URL pointing at whichever service it uses, plus two encryption keys called p256dh and auth. #### What VAPID keys actually do You generate one key pair for your whole application. The public key goes into the subscribe call in the browser. The private key signs a token that travels with every message you send, which proves to the push service that you're the same sender the user agreed to hear from. Regenerate those keys later and every existing subscription stops working, so store them somewhere safe from day one. Your payload gets encrypted in the browser's favour using the subscription keys, so the push service passes the message along without being able to read it. ## UX/UI design built around *real* psychology We design app interfaces around how people actually think and behave. User research, psychology-driven UX/UI design and technical specs delivered as one complete package. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Adding Push Notifications to Your PWA: The Build Steps The build order matters, because each step depends on the one before it. Skipping the manifest work and going straight to the permission prompt is the fastest way to end up debugging something that was never going to work on iOS. 1. Serve everything over HTTPS, with a valid certificate. Localhost works for development. 2. Add a web app manifest with a name, icons at 192px and 512px, and display set to standalone. 3. Register a service worker at the root scope so it controls every page on the site. 4. Generate a VAPID key pair and keep the private key on your server. 5. Request permission inside a click or tap handler, never on page load. 6. Call pushManager.subscribe with your public key, then post the subscription object to your server and store it against the user. 7. Handle the push event in the service worker and call showNotification, then handle notificationclick to focus an open tab or open a new one. On the server side, the web-push library for Node, PHP, Python or Ruby handles the encryption and the VAPID signing for you. Watch the response codes. A 410 or a 404 means the subscription is dead and you should delete it rather than keep retrying. ## The iOS Problem: Home Screen Installation and Apple's Rules Safari gives you no install prompt to trigger. On Android, Chrome fires a beforeinstallprompt event you can hook into with your own button. On iPhone, the person has to tap the Share icon, scroll down, find Add to Home Screen, and confirm. Three deliberate steps that nobody does by accident. That means the install has to be sold inside your interface. A small, well-timed panel showing the exact Share menu icon, explaining what they get, shown after someone has already found the product useful. Asking a first-time visitor to install anything is asking too early. Detect standalone mode with window.matchMedia('(display-mode: standalone)') and only show your permission prompt once the web app is actually running from the Home Screen. Prompting inside a Safari tab on iOS throws an error and burns the moment. Once installed, iOS web push behaves well. Notifications land in Notification Centre, respect Focus modes, and support the Badging API for the little red count on your icon. Action buttons and images are dropped, so write for title and body alone. Expect a lower opt-in rate on iPhone regardless. Native app data from [Mobiloud](https://www.mobiloud.com/blog/push-notification-statistics) puts overall push opt-in at 67.5%, split 43.9% on iOS against 91.1% on Android, and that gap is about platform habits rather than anything you've built. ## Browser and Device Support You Need to Plan Around Support is broad now, and the edges still catch people out. The most common one is [in-app browsers. Someone tapping your link](https://weareaffective.com/learning-centre/what-features-must-your-social-media-app-include-to-succeed) from Instagram or TikTok lands in a webview where service workers are restricted, so your subscribe call fails quietly and you never find out. | Platform | Web push | Watch out for | | --- | --- | --- | | Chrome and Edge, Android | Yes | Battery saver delays delivery | | Firefox and Samsung Internet, Android | Yes | Image handling varies | | Chrome, Edge, Firefox, desktop | Yes | Browser has to be running | | Safari, macOS 16 and up | Yes | Permission needs a real tap | | Safari, iOS and iPadOS 16.4 and up | Home Screen only | No install, no push | | In-app browsers | No | Service workers blocked | Feature-detect before you do anything. Check for serviceWorker in navigator, PushManager in window, and Notification in window. Where any of those are missing, hide the prompt entirely and fall back to email or SMS for that person. A broken enable button does more damage than no button. Android devices with aggressive battery management delay delivery by minutes or hours. Build your messaging so a late arrival still makes sense. ## Choosing a Push Backend: Firebase, Self-Hosted and the MVP Trade-Off On a surveying app we built for performance coaches, we used [Firebase's real-time database as the backend](https://weareaffective.com/learning-centre/should-i-build-my-mobile-app-in-house) for the MVP rather than building a traditional API. Each survey the presenter created wrote a record into Firebase, and audience members reached their own unique response record through keys embedded in the QR code URL. Responses logged in real time, security stayed tight because people could only read and write their own record, and the build stayed small enough to suit a proof of concept. That same reasoning applies to push. Firebase Cloud Messaging handles subscription storage, retries and cross-browser delivery, and it costs nothing at the volumes an early product sees. For a first version, it's usually the right call. #### When self-hosting makes sense The web-push library plus your own database gives you full control, no vendor account, and subscription data that lives with everything else you know about the user. You write the scheduling, the segmentation and the reporting yourself, which is real work. Managed platforms like OneSignal, Braze or Customer.io sit between the two. You get segmentation, scheduling and dashboards out of the box, and you pay per subscriber once you grow. Pick based on who's going to send the messages. If a marketing team sends them, buy the dashboard. ## Asking for Permission Without Losing the User The single biggest change any team can make here is asking permission rather than telling people what they need to hand over. Not the browser dialog, which you don't control, but the moment before it. "Is it okay if we send you notifications when your order ships?" sits very differently to a permission box that appears two seconds after landing. It's purely a framing and tone of voice change, and it has nothing technical in it. People become psychologically far more bought into a product they feel they have some control over, and they stay engaged and retained even though the end result is identical. > People give you more when you ask permission than when you tell them what to hand over. So run your own soft prompt first. Explain what you'll send and roughly how often, then only fire the native dialog when somebody says yes. A no on your panel costs you nothing, because you can ask again next week. A no on the browser dialog is permanent in practice. Timing the ask around something the person already cares about works better than asking on arrival. Apps that hold permission requests back until they're contextually relevant see grant rates up to 28% higher, according to [Dogtown Media](https://www.dogtownmedia.com/the-ask-when-and-how-to-request-mobile-app-permissions-camera-location-contacts/). ## Getting the Timing Right: Why Fixed Delays Fail When we designed the notification timing for a concierge app for residents moving into a new block of flats, we refused to use fixed delays like "two days after move-in". We ran focus groups and scenario research instead, to understand how people actually behave when they move home. What came out of that was simple and specific. Someone who arrives at the property in the morning starts unpacking that day. Someone who arrives in the evening probably won't touch a box until tomorrow. A single person takes longer to unpack than a household of two or three, so the same message needs to land at a different point for each of them. So we built dynamic timing. The system worked out when to send each notification based on arrival time at the property and the number of occupants, rather than running everyone through one schedule. #### Why the window matters more than the message Sending inside a person's preferred time window lifts open rates by up to 40%, according to figures collected by [WiserNotify](https://wisernotify.com/blog/push-notification-stats/). Our experience points the same way, and the useful version of that is behavioural rather than clock-based. Work out what the person is doing when your message arrives, then pick the moment from that. ## Drip-Feeding Content Instead of Dumping It The residents in that concierge app were typically high-net-worth individuals moving into a new building, and we made a deliberate decision not to surface all the building information at once. The full directory existed. Recycling locations, emergency procedures, parking, local area guides, all of it ready to hand over on day one. We chose to hold it back. The emotional state of someone who has just moved is varied and often overwhelming. Some of those users had just bought their first property. Others were moving in after a separation or divorce. People in those states aren't mentally receptive to large volumes of information, whatever the information happens to be. So the content came out over time, matched to when people would actually need it. Recycling information a couple of days after move-in. Local area recommendations over the first weekend. The aim was to unburden users of the tasks and information they'd otherwise have to carry all at once. Map your onboarding content against the days and weeks after signup, then ask of each item, does this person need this today? Anything that fails moves to a later trigger instead of the welcome screen. We pushed for this against the default approach of delivering everything upfront, and the client accepted the recommendation. ## Designing Notifications That Reduce Stress Rather Than Create It We A/B tested the drip-fed approach on that concierge app and ran research and testing with real users afterwards. The stress levels reported by people who received the delayed notifications were much lower than those who got everything at once. That's the measure that mattered to us, more than open rates. What changed was how people read the notification itself. A push that arrives at the right time, about the right thing, stops being an alert about something wrong or something urgent. It becomes the next helpful piece of information, arriving when it's useful. The mental model shifts from "this app is bombarding me" to "this app is actually helping me", and those two states produce completely different retention curves. That decision was also an expression of the wider product idea. The building wanted something human and community-oriented. A product that dumps everything on you at once contradicts that promise, whatever the copy on the welcome screen says. Notification timing was part of the emotional design, sitting alongside the tone of voice and the visual work. So write each message as help rather than instruction. "Your recycling point is on level minus one, here's the map" does more for retention than "Action required". ## Giving Users Real Control Over Frequency Notifications on and notifications off is a terrible choice to give someone. It forces people who want one kind of message to accept all of them, and the usual outcome is that they turn everything off and never come back. A granular breakdown works better. Ask what types of update someone wants, then line the content up with the goals and preferences you've already picked up from how they use the product. Someone who only ever opens your app to check a booking gets booking updates and nothing else. > If someone can cut your notifications in half and lose nothing, you were sending too much. That's a genuinely useful diagnostic to run on your own product. Ask whether a user can reduce the frequency without losing real value. Where they can, the current cadence exists for your retention numbers rather than their benefit, and people notice that faster than teams expect. The appetite for frequent messaging is thinner than most roadmaps assume. [Statista's 2021 US survey](https://www.statista.com/statistics/1243276/us-users-opinion-appropriate-app-notifications/) found only 23% of users consider multiple reminder notifications a day acceptable, and over 20% said they never want brand promotion notifications at all. ## When a PWA Is the Wrong Choice for Re-Engagement When we worked on that surveying app for performance coaches, we recommended against making the audience download a native app. It was too high a barrier for what was essentially a simple, one-off touchpoint in the middle of a presentation. We proposed a QR code instead. The presenter creates a survey in the native app, a QR code appears on screen, and anyone scanning it with their phone lands immediately on a branded, fully mobile-responsive page. It felt like a native app without the app store step, and a lot more people finished the survey. That product never needed push at all. The re-engagement happened in the room. #### Where native still wins Push should go native where it carries the product. If your retention model depends on daily reminders reaching an iPhone-heavy audience, the Home Screen install step puts a wall between you and most of them. [Fitness and wellness products with streaks, scheduled reminders](https://weareaffective.com/learning-centre/fitness-app-trends-2026-what-users-really-want-from-their-workout-apps) or location-based prompts hit the same wall, because web push has no local scheduling and no geofencing. A PWA suits products where push supports the experience. Order updates, booking changes, restocks and account activity all work perfectly well over web push. ## Measuring Whether Your Notifications Are Working Open rate on its own tells you very little. Push open rates average around 4% in [Customer.io's platform data](https://customer.io/learn/mobile-marketing/push-notification-metrics), and they describe that as normal rather than a failure. Treating 4% as a problem to fix usually leads teams to send more, which is the opposite of what the number is telling them. Four things are worth tracking properly. - Opt-in rate, split by platform, because iOS and Android behave differently. - Opt-out and unsubscribe rate per campaign type, which shows you exactly which messages people resent. - Subscription decay, meaning how many stored subscriptions return a 410 over time. - Retention at day one and day thirty for people who opted in against people who didn't. Day one retention is the early warning. If most new users never come back the day after signup, that's borderline and worth treating as a problem, and the real goal is carrying people past day one and into day thirty and beyond. That matters most when you're paying for acquisition, because the spend has to be justified somewhere. Qualitative research belongs here too. We only knew the drip-fed notifications reduced stress because we asked people how they felt, and no dashboard reports that. ## Common Faults and How to Diagnose Them Most push bugs come from a handful of causes, and they all look like the same symptom, which is nothing arriving. - Nothing on iPhone. Check the web app is running from the Home Screen, not a Safari tab, and that iOS is 16.4 or later. - "This site has been updated in the background" appears. Your push event handler finished without calling showNotification. - Subscribe call fails silently. You're probably in an in-app browser, or the service worker scope doesn't cover the page. - Everything stopped at once. Someone regenerated the VAPID keys, which invalidates every existing subscription. - Gradual decline in delivery. Dead subscriptions returning 410 are still sitting in your database. - Delivery hours late on Android. Battery optimisation on the device, outside your control. Log the HTTP status for every push you send and store it against the subscription. Delete on 404 and 410, retry on 429 and 5xx, and alert yourself when 403s appear, because that's a VAPID problem rather than a user problem. [Test on real devices](https://weareaffective.com/learning-centre/what-are-the-different-types-of-mobile-app). Desktop Chrome lies to you about Android battery behaviour, and the iOS Simulator doesn't support web push at all. Keep an old Android handset and a mid-range iPhone on the desk. ## Conclusion You can send push notifications from a PWA, on every platform that matters, and the engineering side is a few days of work for a team that's done it before. Service worker, VAPID keys, a subscription store and a sender. None of it is hard. The part that decides whether it works sits somewhere else entirely. On the concierge app, the thing that lowered people's stress wasn't the delivery mechanism, it was the research that told us a person arriving in the evening wouldn't unpack until the next day. Dynamic timing based on arrival time and household size came out of focus groups, not out of a push library. So treat the build as the small half of the job. Spend the time on what you send, when it lands, how you ask for permission, and how much control you hand back afterwards. Ask whether someone can reduce the frequency without losing anything real, and act on the answer. If you're weighing up PWA push notifications for a product and you want a view on whether the iOS install step is going to cost you more than it returns, [let's talk about your notification strategy](https://weareaffective.com/get-started). ## Frequently Asked Questions Can I send push notifications from a PWA on iPhone? Yes, but only if the user adds your web app to the Home Screen first. Safari will not grant push permission to a site running in an ordinary browser tab, so a tab visit gets you nothing. Apple added this capability in iOS 16.4 in March 2023. Do users need to install anything on Android or desktop? No. On Android, Windows, macOS, Linux and ChromeOS, someone visiting your site in Chrome, Edge, Firefox, Opera or Samsung Internet can grant permission and start receiving pushes with no install step. The notification will appear even when the browser is closed. What are service workers, the Push API and VAPID keys? A service worker is a small JavaScript file the browser keeps running separately from your pages, so it can wake up and display a notification when your site is closed. The Push API is how that service worker registers to receive messages, and VAPID keys are a public and private key pair that prove to the push service that the message genuinely came from you. Do I get to choose which push service delivers my messages? No, the push service belongs to the browser vendor. Chrome uses Firebase Cloud Messaging, Firefox uses Mozilla's autopush and Safari uses Apple's own service. When a user subscribes, the browser hands you an endpoint URL for whichever service applies, along with the p256dh and auth encryption keys. What can a PWA push notification actually contain? Every platform supports a title, body, icon, badge, a URL to open on tap and grouping by tag. On Android and desktop you can also use action buttons, large images and vibration patterns. iOS Safari strips out the action buttons and images, so plan your core message around the text alone. Can I send silent background pushes or schedule notifications locally? No on both counts. Chrome requires you to display a visible notification for every message you send, so silent background pushes are blocked. There are also no scheduled local notifications, which means every push has to be triggered from your server. What happens if a user deletes the Home Screen app on iOS? The push subscription is wiped completely. They would need to add the web app to their Home Screen again and grant permission from scratch before any notification could reach them. What if someone denies the permission prompt? A denial in the browser is very hard to recover from, so the first ask matters enormously. Trigger the prompt at a moment when the value is obvious to the user rather than on first page load, and explain what they will receive before the browser dialogue appears. ## Related Articles [![whats-the-psychology-behind-successful-push-notifications](https://weareaffective.com/hubfs/learning-centre-images/whats-the-psychology-behind-successful-push-notifications.webp)](https://weareaffective.com/learning-centre/whats-the-psychology-behind-successful-push-notifications) ### [What's The Psychology Behind Successful Push Notifications?](https://weareaffective.com/learning-centre/whats-the-psychology-behind-successful-push-notifications) 97% of mobile apps are deleted within 30 days of being downloaded. That's a staggering number when... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![How Do Push Notifications Work on iOS and Android?](https://weareaffective.com/hubfs/learning-centre-images/how-do-push-notifications-work-on-ios-and-android.webp)](https://weareaffective.com/learning-centre/how-do-push-notifications-work-on-ios-and-android) ### [How Do Push Notifications Work on iOS and Android?](https://weareaffective.com/learning-centre/how-do-push-notifications-work-on-ios-and-android) A push notification covers a surprising amount of ground before a phone buzzes. The message leaves... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![Local vs Global When to Adapt Your Mobile Strategy](https://weareaffective.com/hubfs/learning-centre-images/local-vs-global-when-to-adapt-your-mobile-strategy.webp)](https://weareaffective.com/learning-centre/local-vs-global-when-to-adapt-your-mobile-strategy) ### [Local vs Global When to Adapt Your Mobile Strategy](https://weareaffective.com/learning-centre/local-vs-global-when-to-adapt-your-mobile-strategy) We worked on a currency exchange product with a neat idea behind it. People come home with leftover... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.