safari push notifications javascript

• Using array.splice

How to send PWA Push Notifications in Safari IOS 16

Keep an eye out for web push on ios and ipados in 2023..

After long delays IOS 16 is finally adding push notifications for PWA's. But how do you actually implement it and make it work with JavaScript?

Starting September 2022 you can add native Push Notifications to your PWA. Until then...

First...you need to turn on Push API in experimental mode on your IOS 15

The Push Notification API is already available in IOS 15, but only in "experimental mode".

While Push API already exists by default it is turned off. So you need to turn it under Settings.

How to enable Push API While waiting for IOS 16 you can turn on Push API on your iPhone by going to Settings , typing Safari in search, click on Safari , scroll all the way down and go to Advanced and tap on Experimental Features . Now scroll down to where it says "Push API", and enable it by tapping on green switch button to turn it on.

Some preliminary setup is required. Here's step-by-step JavaScript tutorial.

Step 1: How To Create and Register a Service Worker (serviceworker.js)

First, create your service worker JavaScript file and place it in root directory of your PWA. I named my service worker serviceworker.js but the name can be anything.

Then, we will need to register this JavaScript file as your service worker.

The serviceWorker object and its method register() reside on the built-in navigator object.

In the next example, let's use JavaScript to check if a service worker is already registered. If not this code will register a service worker . Additionally, you might want to run this code from your DOMContentLoaded event.

More coming soon...

Why was this tutorial written?

When team here at Ghost Messenger heard of this news we got excited and decided to implement it on our PWA. In this tutorial we will explain how we got it to work in our app and hopefully others can follow in our footsteps to install Push API in their own PWA.

The rest of this article is coming soon.

HTML comments above are special tags, they will be replaced with H1 title and your author info. If you don't want to include that in your article delete or modify comment.

Place additional scripts or CSS above tag.

You can create bold text and lists as follows:

Example of an UL list

Example of an OL list

You can create source code tags by wrapping text in back-tick quotes.

You don't have to use p tags to create paragraphs, but you still can.

It's recommended to keep author tag so that readers who come from search engine traffic can also discover your social network links and bio.

Note: You can use regular HTML in this article but be careful not to break anything.

Comments (2) New! (You can now post comments on articles!)

• Skip to main content
• Skip to search
• Skip to select language
• Sign up for free
• English (US)

Using the Notifications API

Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers .

Note: This feature is available in Web Workers .

The Notifications API lets a web page or app send notifications that are displayed outside the page at the system level; this lets web apps send information to a user even if the application is idle or in the background. This article looks at the basics of using this API in your own apps.

Typically, system notifications refer to the operating system's standard notification mechanism: think for example of how a typical desktop system or mobile device broadcasts notifications.

The system notification system will vary of course by platform and browser, but this is OK, and the Notifications API is written to be general enough for compatibility with most system notification systems.

One of the most obvious use cases for web notifications is a web-based mail or IRC application that needs to notify the user when a new message is received, even if the user is doing something else with another application. Many examples of this now exist, such as Slack .

We've written a real-world example — a to-do list app — to give more of an idea of how web notifications can be used. It stores data locally using IndexedDB and notifies users when tasks are due using system notifications. Download the To-do list code , or view the app running live .

Requesting permission

Before an app can send a notification, the user must grant the application the right to do so. This is a common requirement when an API tries to interact with something outside a web page — at least once, the user needs to specifically grant that application permission to present notifications, thereby letting the user control which apps/sites are allowed to display notifications.

Because of abuses of push notifications in the past, web browsers and developers have begun to implement strategies to help mitigate this problem. You should only request consent to display notifications in response to a user gesture (e.g. clicking a button). This is not only best practice — you should not be spamming users with notifications they didn't agree to — but going forward browsers will explicitly disallow notification permission requests not triggered in response to a user gesture. Firefox is already doing this from version 72, for example, and Safari has done it for some time.

In addition, In Chrome and Firefox you cannot request notifications at all unless the site is a secure context (i.e. HTTPS), and you can no longer allow notification permissions to be requested from cross-origin <iframe> s.

Checking current permission status

You can check to see if you already have permission by checking the value of the Notification.permission read only property. It can have one of three possible values:

The user hasn't been asked for permission yet, so notifications won't be displayed.

The user has granted permission to display notifications, after having been asked previously.

The user has explicitly declined permission to show notifications.

Getting permission

If permission to display notifications hasn't been granted yet, the application needs to use the Notification.requestPermission() method to request this from the user. In its simplest form, we just include the following:

This uses the promise-based version of the method. If you want to support older versions, you might have to use the older callback version, which looks like this:

The callback version optionally accepts a callback function that is called once the user has responded to the request to display permissions.

Note: There's no way to reliably feature-test whether Notification.requestPermission supports the promise-based version. If you need to support older browsers, just use the callback-based version—although this is deprecated, it still works in new browsers. Check the browser compatibility table for more information.

In our todo list demo, we include an "Enable notifications" button that, when pressed, requests notification permissions for the app.

Clicking this calls the askNotificationPermission() function:

Looking at the second main block first, you'll see that we first check to see if Notifications are supported. If they are, we run the promise-based version of Notification.requestPermission() , and if not, we log a message to the console.

Inside the promise resolution handler passed to then , we show or hide the button depending on what the user chose in the permission dialog. We don't want to show it if permission has already been granted, but if the user chose to deny permission, we want to give them the chance to change their mind later on.

Creating a notification

Creating a notification is easy; just use the Notification constructor. This constructor expects a title to display within the notification and some options to enhance the notification such as an icon or a text body .

For example, in the to-do-list example we use the following snippet to create a notification when required (found inside the createNotification() function):

Closing notifications

Use close() to remove a notification that is no longer relevant to the user (e.g. the user already read the notification on the webpage, in the case of a messaging app, or the following song is already playing in a music app to notifies upon song changes). Most modern browsers dismiss notifications automatically after a few moments (around four seconds) but this isn't something you should generally be concerned about as it's up to the user and user agent. The dismissal may also happen at the operating system level and users should remain in control of this. Old versions of Chrome didn't remove notifications automatically so you can do so after a setTimeout() only for those legacy versions in order to not remove notifications from notification trays on other browsers.

Note: This API shouldn't be used just to have the notification removed from the screen after a fixed delay (on modern browsers) since this method will also remove the notification from any notification tray, preventing users from interacting with it after it was initially shown.

Note: When you receive a "close" event, there is no guarantee that it's the user who closed the notification. This is in line with the specification, which states: "When a notification is closed, either by the underlying notifications platform or by the user, the close steps for it must be run."

Notification events

There are four events that are triggered on the Notification instance:

Triggered when the user clicks on the notification.

Triggered once the notification is closed.

Triggered if something goes wrong with the notification; this is usually because the notification couldn't be displayed for some reason.

Triggered when the notification is displayed to the user.

These events can be tracked using the onclick , onclose , onerror , and onshow handlers. Because Notification also inherits from EventTarget , it's possible to use the addEventListener() method on it.

Replacing existing notifications

It is usually undesirable for a user to receive a lot of notifications in a short space of time — for example, what if a messenger application notified a user for each incoming message, and they were being sent a lot? To avoid spamming the user with too many notifications, it's possible to modify the pending notifications queue, replacing single or multiple pending notifications with a new one.

To do this, it's possible to add a tag to any new notification. If a notification already has the same tag and has not been displayed yet, the new notification replaces that previous notification. If the notification with the same tag has already been displayed, the previous notification is closed and the new one is displayed.

Tag example

Assume the following basic HTML:

It's possible to handle multiple notifications this way:

• Notification

Web Push Notifications with Push API in JavaScript

Push notifications are popular for mobile applications that want to keep their users informed of updates, incoming messages, and more. They've been popular since the release of smartphones and will continue to play a major role in mobile applications for a long time ahead.

Another feature, web push notifications, allows users to receive and display real-time notifications within their web browsers with a little bit of JavaScript code and the Push API .

This tutorial will cover what web push notifications are and how to set them up within a website or web application.

• What Are Web Push Notifications?

Web push notifications are real-time notifications submitted to a user's desktop or mobile browser through either a server-side application or web push service. These types of notifications can be used to engage or re-engage a user in a website's content or provide personalized messages, notifications, or alerts.

Web push notifications generally pop up from the right side of the screen, either the top-right or bottom-right, on desktops and from the top of the screen on supported mobile devices, depending on the user's browser and device or operating system.

Here, we'll walk through Google Firebase to set up our project required for sending web push notifications, and create some JavaScript code using the Push API. Finally, we'll create an HTTP request to generate our own custom push notifications.

• Setting Up Web Push Notifications
• Step 1: Set Up a Google Firebase Project

If you don't have a Google account, you'll need to set this up first. If you do have a Google account, make sure you're logged in so you can proceed.

First, we'll create a Firebase project in the Google Firebase Console .

Project creation is easy. Click on the big "+ Add Project" button from the Firebase console:

Give our project a name:

Once the project is created, we'll need to add a web platform:

And then provide a name for our platform. This can be the same name as our project to keep things consistent:

Finally, click the "Register App" button to create our new web platform within our Firebase project.

• Step 2: Generate A Vapid Key

A Vapid key, or Voluntary Application Server Identification, is required to subscribe to push notifications and send requests through supported web services.

You can generate a Vapid key straight from the Google Firebase console by navigating to Project Name > Project Settings > Cloud Messaging and scrolling to the Web Configuration section at the bottom of the screen.

Then, click the Generate Key Pair button to generate your new Vapid key:

Save this key for later. We'll need it for generating web push tokens in our code.

• Step 3: Create the Service Worker File

The service worker file is needed to register the Firebase dependencies for notification initialization and handling, and for background notification event handling when the browser window is closed or inactive.

Create a file named firebase-messaging-sw.js that is placed in the root directory of our website.

In the file, we need to import the required Firebase dependencies using JavaScript's importScripts() method:

The JavaScript file versions are redacted from the paths. You can find the latest script versions here.

Next, we need to define our Firebase configuration variables using the values provided from the Firebase console, and then initialize Firebase. This is just an example. The code you need can be copied and pasted from your Firebase configuration as it will contain the correct keys and IDs for your project:

Finally, we need to create a firebaseMessaging object and onBackgroundMessage() method for background badge count retrieval and display. The badge count is an optional thing, but useful for your users when they want to know if they have new notifications before opening your web app.

• Step 4: Initialize Firebase in Our Website

Now, we'll initialize Firebase within our website for foreground message handling. Foreground messaging allows our web browser to receive real-time notifications when our web browser is active, or in the foreground.

Create a JavaScript file named push.js and place it in the root directory of your website. This is where we'll work with all client-side code related to web push notification handling.

First, we'll need to include the script from our HTML code as a module type. This is required when working with web push notifications through Firebase:

Second, we need to include our Firebase dependencies. These files should always be included before any other Firebase-specific functions. Just make sure to replace the version numbers to the same versions in the service worker file above:

Third, we'll initialize Firebase from the frontend:

And, fourth, we'll create a variable named registration we'll use to hold our service worker registration data and register the service worker. This is required to send web push notifications as needed:

• Step 5: Request Permissions

Before sending web push notifications, we'll need to request permissions. Let's create a custom function that will handle this functionality:

Here, we've created a custom function called PushPermission() that accepts no parameters. This function can be called whenever you want to request web push permissions from your users.

As a quick overview, we've created a promise that will either return an acceptance or rejection. A permission request is generated for the user in their browser window using the Notification.requestPermission() method from the Push API and passing the result through our permissionResult variable. If they grant permissions, we call another custom function PushSubscribe() that we'll cover shortly. Otherwise, an error will throw confirmation permissions were denied by the user.

The permission request will generate a native popup that looks like this:

However, it's best practice to show a more user-friendly version of the permissions you're requesting before showing this native popup. This is something that you can customize on your own, providing some details about what the user is subscribing and agreeing to and what types of notifications and frequency of notification submissions they should expect. The native popup is still required. This just gives your users more of a heads-up on what you're requesting of them and what to expect:

• Step 6: Register a Web Push Token

Once the user has accepted the permissions, we'll generate a token for them. This token is a user's unique ID that Google Firebase will need when sending direct push notifications.

Here, we've created another custom function named PushSubscribe() that handles the token generation and subscribes the user to notifications.

We call Push API's getToken() method and pass in our firebaseMessaging instance and our vapid key we created in our Firebase Console project earlier. If a token is returned, we can do whatever we need with it. We'll need to reference it later when sending push notifications, so I'd recommend storing the token in a database or somewhere on your server where you can get to it.

• Step 7: Create a Foreground Notification Event Handler

Next, we'll need a way to handle incoming notifications when the browser window is in the foreground, or when a browser tab is active.

We'll reference the firebaseMessaging instance again to assign an onMessage event handler, which will listen for any incoming messages in the foreground:

The event handler returns one parameter, payload , containing the data we'll use to display in the user's notification popup on their screen using the payload data provided in the notification data.

We'll reference the registration instance created from our service worker and call the showNotification() method to display the notification to the user. In this example, we're passing the payload notification data and any options that may exist for display and user interaction, including a custom 512x512 pixel icon. This icon can be anything, but typically is a logo.

• Step 8: Send A Web Push Notification

Once a user has accepted web push permissions, and a valid token has been generated and stored somewhere on the server, they can begin receiving notifications.

Now, we'll need our Firebase server key to grant authentication from Google's services to submit the notifications via FCM. The Firebase server key can be found in Firebase under Project Settings > Cloud Messaging , then grab the Server Key value:

Next, we'll generate web push notification with a user token using cURL:

Here is the minimal payload data needed to send a web push notification:

You can expand native push notifications for iOS and Android devices or add notification click details with additional payload data:

Successfully received notifications will appear like this:

This is a Chrome browser notification. Other browsers and devices may displa these notifications differently, but the overall concept remains the same.

• Notification Options

There are four noteworthy options you can use when displaying notifications:

• body : Notification description shown below the notification title. This should give the user enough information to decide how to act on the notification. Make it useful to our users or you may miss out on subscription opportunities.
• icon : Attaches an image to the notification to make it more appealing and relevant to our site and the user. You could make this our site icon, a user profile image, or any other type of image that uniquely identifies our website.
• vibrate : This one's fun to play around with. Here, you can specify a vibration pattern for a mobile device receiving the notification. This is done using an array of values. For example, [100, 50, 100] would vibrate for 100 milliseconds, pause for 50 milliseconds, then vibrate again for another 100 milliseconds.
• data : Any additional custom data you would like to pass into the browser when the user clicks on the incoming notification. This is an object that can accept a set of key/value pairs.
• Some Useful Tidbits
• The HTTPS protocol is required. You can only use web push notifications within a secure connection. Learn how to secure your website with HTTPS here .
• It's better to use a custom popup with a friendly message and details about what they'll be subscribing to versus just showing the native "Allow" or "Block" popup in the corner initially. Doing so can help gain user trust and give them a heads up of what they're subscribing to ahead of time, allowing them to make a more informed decision. It may be a good idea to include the notification frequency; how many times we'll be submitting notifications per day, week, or month.
• If you're going to implement this feature, it's best to use a timed popup delay or wait until the user has scrolled down a certain amount on our web page before showing them a popup. There's nothing worse than visiting a web page and getting bombarded with tons of popups and flyouts on the get-go. Make sure to keep our user's best interests in mind.
• Browser Support

Chrome, Firefox, Opera, Edge, and Safari support web push notifications on desktop devices.

Notifications in Chrome for Android and Safari for iOS as of v16.4 are also supported.

The notifications will vary in appearance and position between the different browsers and operating systems.

Now you are familiar with the ways of implementing web push notifications with JavaScript and the Push API.

They are a fantastic solution to keeping our users informed of new content or updates within our website or web application.

Just remember to keep your user's best interests in mind when implementing this feature. Don't spam them with needless messages. And make sure permission requests and popups aren't providing an overall bad user experience.

There are no comments yet. Start the conversation!

Add A Comment

Table of contents, more javascript.

• Apr 18, 2022

The Ultimate Guide To Push Notifications For Developers

• 12 min read
• Apps , Mobile , Guides , User Experience
• Share on Twitter ,  LinkedIn

About The Author

Lee Munroe is Head of Design for OneSignal and creator of HTMLemail.io , based in San Francisco. More about Lee ↬

Email Newsletter

Weekly tips on front-end & UX . Trusted by 200,000+ folks.

I’ve spent the past several years building messaging tools — for more than three years now I’ve been leading the design team at OneSignal , a customer engagement platform that enables developers and marketers to send transactional and promotional messages via push, in-app, email and SMS. I’ve learned a lot about how messaging works including the pros and cons of using push to communicate with your audience. In this post, I’ll brain dump all of my knowledge on the topic.

Introduction To Push

Push notifications are clickable messages that pop up on your phone or desktop with some content. Typical types of push notifications include:

• Promotional New blog post, new release, a Black Friday sale, etc.
• Transactional New message received, a friend liked your comment, your driver is on their way, appointment reminders, etc.

Push notifications were originally introduced in 2009 by Apple with APNs (Apple Push Notification service). Google quickly followed for Android (which later became FCM ) and in 2013 web push was introduced for Chrome.

Push is still a relatively new communication technology compared to its siblings. The first email was sent in 1971 (50 years ago!) and the first SMS was sent in 1992 (30 years ago!). Marketers and developers are still discovering where push fits into their communication stack, so while most companies have an email strategy for customer engagement, most don’t have a push strategy yet.

Push is very similar to these other communication channels like email. You use them to engage with your customers. You can send promotional or transactional content. You need a way for people to opt-in and opt-out . You need to segment your audiences. You need to personalize your messages. You need to compose your message, send your message, view reporting for your message, and so on.

Why Use Push Notifications?

There are several benefits of push over other messaging channels:

• Push typically sees higher engagement than email — 20% open rate vs 2% ;
• Push doesn’t require users to hand over any personal information like an email address or phone number;
• Push is cheap to send (unlike SMS which is upwards of 2c per message);
• Push is quick to send;
• Push has a high opt-in rate (see more below).

What can you use push notifications for?

• Abandoned cart Get users back to complete the checkout process.
• Onboarding Welcome users to your app and get them up and running.
• Announcements New features, updates, and upcoming events.
• Offers Discounts and rewards.
• Rewards & delight Make users feel good with rewarding progress in a game.
• Live updates News, scores, order status.

How To Implement Push Notifications

You can build your own push service on top of the different APIs and operating system platforms available. iOS has APNs . Google has FCM . Web browsers use Service Workers , Notification API and the Push API . When building your own you need to consider the push service, managing subscribers, permission prompts, message composition, delivery and reporting.

Unless you’re a big company with a full team of engineers you can dedicate to maintaining such a service, you should just use a push service that exists . Just like you’re unlikely to build your own internal email service, the same applies to push.

As push APIs are updated with each new iOS or Android release , it makes sense to let a service provider do the heavy lifting here so you’re not left maintaining that system . There are services that offer easy-to-use UIs, SDKs and APIs. Some of the best push notification providers for developers and marketers include:

• OneSignal ,
• Google Firebase ,
• Amazon SNS ,

Aren’t Push Notifications Annoying?

They absolutely can be, yes. Just like sending irrelevant emails or too many text messages is annoying and spam. This is not a fault of the technology itself, but we as website owners and app developers abusing their power.

For example, a lot of websites or apps immediately prompt users to subscribe to push. This is just as frustrating as a blog you land on immediately surfacing a pop-up asking you to subscribe to their email newsletter. At this point, you have no idea what they do or if there’s value in subscribing.

Don’t do this. Treat your app users and website visitors with respect. In fact, browsers have started clamping down on websites that do this, and instead hide the prompt until the user notices it and clicks on it.

Prompting Best Practices

Permission opt-ins differ across operating systems and industries:

• iOS Users must explicitly opt-in for push when they download your app, the average opt-in rate ranges 35–45% .
• Android Users are automatically opted in to receive push notifications, the average opt-in rate ranges 35–45% .
• Web push Users must explicitly opt-in for push when they visit your website, the average opt-in rate ranges 7–17% .

Only prompt users to subscribe after they have had an opportunity to find value e.g. after at least 1 pageview, or after they have taken an action where it would be useful for them to know when there’s an update.

Use soft prompts. You only have one opportunity to ask users with the native prompt, after which it is painful to ask them to go into settings and allow you to send them messages. Use your one opportunity wisely.

Prompting Mistakes

“Push notifications became yet another way to artificially re-engage users and force content down their throat. That’s why so many of them hate it. But there are some interesting use cases for it.” — The Ultimate Guide to Not F#!@ing Up Push Notifications , Stéphanie Walter

Asking For Permission Immediately

Don’t do this. Allow users to experience your app or website first and the value you provide. Delay your prompt at least a pageview or by some time so users have an opportunity to look around. Or wait until the user is taking action and then present them with an option to subscribe.

Not Telling Users What Notifications Will Contain

Make users aware of the value of your push notifications. Will they notify me of new sales and promotions? When someone sends me a message? When there’s a new blog post? Make it clear so users can decide if these are the types of messages they want to receive.

Don’t Make It Hard To Opt-out

Allow users to edit their notification preferences within the app. Just like an email preference center, users may want to unsubscribe from all notifications or a certain category of notification e.g. stop sending me every blog update but do send me new feature announcements.

Don’t Send Too Many Notifications

Set expectations upfront on how often you expect to send notifications. Then stick to that. Depending on what industry you’re in this could be many per day e.g. breaking news alerts, or once a week e.g. meditation app.

Where Are Push Notifications Supported?

• ✅ iOS native apps,
• ✅ Android native apps,
• ✅ macOS Chrome/Firefox/Safari,
• ✅ Windows Chrome/Firefox/Edge,
• ✅ Android Chrome/web browsers,
• ✅ macOS native apps,
• ✅ Windows native apps.

Not supported

• 🚫 Safari on iOS does not support notifications.
• 🚫 All other iOS browsers like Chrome and Firefox for iOS do not support notifications.
• 🚫 Push notifications do not work in incognito or private browser mode.

See the state of push notification support for a more detailed and up-to-date look at all devices like watchOS, Amazon Echo, TVs and others.

Anatomy Of A Web Push Notification

The anatomy and design of push notifications change across operating systems and browsers. For the most part, the key elements are:

Here are examples for the main operating systems and browsers:

Web Push, Chrome For macOS Monterey

• Browser Icon Chrome icon. This can’t be changed.
• Title Restricted to 60-80 characters.
• Domain Website user is subscribed to. Can’t be changed.
• Icon 192×192 or larger. PNG, JPG, GIF (not animated). Enlarges when expanded.
• Content Restricted to 120-150 characters.
• Action Buttons Supports up to 2 buttons.

Web Push, Chrome For Windows 11

• Banner Image 360×180 or 2:1 aspect ratio. PNG, JPG, GIF (not animated).
• Browser + Browser Icon Can’t be changed.
• Icon 192×192 or larger. PNG, JPG, GIF (not animated).
• More Options Includes notification settings and focus assist.
• Dismiss Closes the notification.
• Title Restricted to 60 characters.
• Content Restricted to 120 characters.

Mobile Push For Android 12

• Small Icon 24×24 - 96×96 to fit all device sizes. Must be white with a transparent background. PNG.
• Title Restricted to 50 characters.
• Body Restricted to 150 characters.
• Large Picture 1440×720 or 2:1 aspect ratio. PNG, JPG, GIF (not animated).
• App Name Can’t be changed.
• Time Stamp Time message received.
• Action Buttons Supports up to 3 buttons.

Mobile Push For iOS 15

• App Icon Uses the app’s default icon and can’t be changed.
• Rich Media 1024×1024 or 1:1 aspect ratio. PNG, JPG, GIF, MP4, MP3, WAV.
• Title Restricted to 25-50 characters.
• Time Stamp When the message was received.
• Message Restricted to 150 characters.
• Action Buttons Supports up to 4 buttons.

Note : For more examples across each device and operating system, see push notification anatomy .

Sending Best Practices

Don’t just carelessly blast push notifications to all your subscribers. Consider who your users are, their context, and the value they will get from your content and service.

• Messages should be timely, relevant, and precise .
• Use emojis , they tend to help CTR.
• Make sure your content is valuable .
• Personalize , use the subscriber’s name or something relevant to them.
• Use urgency and fomo to help increase CTRs on things like sales.
• A/B test to see what content and images perform better.
• Segment based on user behavior or preferences e.g. geographic location, level of engagement.
• Schedule per user’s timezone , make sure they don’t receive messages in the middle of the night.
• Keep the content short and concise , and get to the point.

Analytics and ROI

Numbers you want to keep an eye on:

• Opt-in rate Percentage of users or visitors that are opting in to push, adjust your message, or when you are promoting to improve this.
• Deliverability How many messages actually got delivered to user devices.
• Open rate The number of messages that were clicked divided by the messages sent.
• Outcome/goal/conversion What was the end goal, e.g. a purchase or plan upgrade? Opt-in rates and open rates are often considered vanity metrics, what you really care about is did they produce an outcome.

For web push, use UTMs to help track attribution. For mobile push, services like AppsFlyer and Branch can help with attribution tracking.

Why Am I or My Users Not Receiving Push Notifications?

Here are some of the most common reasons I’ve seen.

Users Haven’t Subscribed To Your App

Ask them to subscribe. Check that they are subscribed. Look up their user’s ID you’ve defined or push token.

Users Have Turned Off Notifications For Your App Or Website

Ask users to check their app settings or browser settings and ensure they haven’t blocked you.

Users Have Turned Off Notifications For The Browser They Are Using

Or they never gave it (the browser) permission in the first place. Operating systems will ask users permission to send notifications via their browsers, and often users will ignore these. Ask them to check their app level notification settings in their OS.

Users Have Turned Off Notifications For The OS They Are Using

Some users will turn off all notifications for their OS, intentionally or accidentally. Check their OS settings for notifications. For example, Settings > Notifications > Show Previews > Never will turn off all iOS notifications.

Check settings at your OS level, browser level, and app level to ensure notifications are turned on and you or they have opted in.

The Future of Push Notifications

Ios support for web push.

Web push for iOS Safari has been in high demand for years and recently it looks like they might be ready to give in with a recent update to WebKit . This will be huge if Apple has decided to finally enable this.

Android Opt-In

Starting with Android 13 , users will have to opt-in to receive notifications . There is likely no meaningful long-term effect on opt-in rates, but it will improve the overall ecosystem by giving users control up-front, rather than having to opt-out later.

Omnichannel Messaging

Omnichannel and more integration alongside other messaging channels. Every user has a preference for how they receive messages, and it is important to consider this when personalizing that customer journey with push, email, SMS .

In 2022 it’s even more important to consider your user’s behavior across all these channels, ensuring you automate your messaging and extend your reach across all channels.

Preventing Abuse

Browsers and operating systems are working hard to prevent abuse e.g. making sure websites don’t show prompts immediately to visitors. As mentioned previously, some updates have already been shipped here recently with Chrome, Firefox and Edge to hide prompts on websites that are immediately prompting on page load, and there is sure to be more to follow.

If you run a website or app today and you’re not sending push notifications, you should add it. If you’re already sending email, SMS or in-app, you should add push to your stack. As long as you make sure the content is valuable and follow the best practices above, it’s an opportunity for you to re-engage and your users will be grateful.

Useful Resources

• “ Privacy UX: Better Notifications And Permission Requests ”, Vitaly Friedman
• Push Notification Generator , Peter Beverloo
• “ Push Notification UI Kit ”, Lee Munroe
• Push Notification Preview Tool , OneSignal
• “ How Push Works ”, Matt Gaunt

Smashing Newsletter

Tips on front-end & UX, delivered weekly in your inbox. Just the things you can actually use.

Front-End & UX Workshops, Online

With practical takeaways, live sessions, video recordings and a friendly Q&A.

TypeScript in 50 Lessons

Everything TypeScript, with code walkthroughs and examples. And other printed books.

• Español – América Latina
• Português – Brasil
• Tiếng Việt

Push notifications are now supported cross-browser

Deliver timely and useful notifications to your users.

Push notifications were standardized in 2016 with the release of the Push API and the Notification API, which are part of the W3C's Web Applications Working Group. These APIs provide the necessary functionality for web developers to incorporate push notifications into their web applications and for users to receive and interact with notifications on their web browsers. Push messages are notifications that are sent to a user's web browser from a website or application that the user has previously granted permission to send notifications. These messages can be used to alert the user of new content or updates, remind them of upcoming events or deadlines, or provide other important information. Push messages can be particularly useful for applications that need to deliver timely, relevant information to their users, such as news or sports apps, or for e-commerce websites that want to send users notifications about special offers or sales.

To sign up for push notifications, first check if your browser supports them by checking for the serviceWorker and PushManager objects in the navigator and window objects.

If push notifications are supported, use the async and await keywords to register the service worker and subscribe for push notifications. Here is an example of how you can do this using JavaScript:

Browser Support

Further reading

• Push notifications overview
• Web Push for Web Apps on iOS and iPadOS

Part of the Newly interoperable series

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License , and code samples are licensed under the Apache 2.0 License . For details, see the Google Developers Site Policies . Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2023-03-28 UTC.

• Become a Contributor
• Browser Push Notification

Safari Push Notifications- Everything You Need To Know

Last updated on apr 01, 2024.

Web push notifications for Safari was introduced in OS X maverick. The Apple Push Notifications Service (APNS) is used to send concise and clickable messages to your website users, on their Mac device. Safari Push Notifications work just like App push notifications . These messages/notifications are delivered even when the Safari browser isn’t running. Each notification displays your website icon and text and you can add a landing page URL to direct the user.

Until recently, Safari push notifications were limited to just Mac OS devices. Apple in 2022, announced that it will be rolling support for web push notifications on Safari starting 2023. 

There are two kinds of notifications for websites:

• Safari Push Notifications , which is an Apple-exclusive technology and triggered remotely using the Apple Push Notification service (APNs) These are delivered to the user's device, even when the app (Safari) is not open
• Local Notifications as specified by W3C standard  and triggered locally using JavaScript. These can trigger notifications to appear as long as the webpage remains in an open tab.

How can you integrate/enable push notifications on Safari?

To integrate push notifications on your website, you first present an interface that allows the user to opt in to receive notifications. If the user consents, Safari contacts your website requesting its credentials in the form of a push package file. The push package also contains notification assets used throughout OS X and data used to communicate to a web service you configure. If the push package is valid, you receive a unique identifier for the user on the device known as a device token. The user receives the notification when you send the combination of this device token and your message, or payload, to APNs.

Upon receiving the notification, the user can click on it to reach the landing page.

Managing notifications: Disable Safari push notifications

Wondering how to stop notifications on safari? By default, users visiting websites that have enabled Safari Push Notifications, such as the users, will see a banner appear at the top of the window the first time the site is visited. Here, the user can choose whether to allow notifications from the website. These notifications will appear as standard Notification Center alerts whenever the site posts new content or manually sends out a notification, including the appearance of a banner on the top-right of the screen and an entry in the Notification Center.

Web notifications look and work like any other notification alert. Their appearance can be customized by the user in System Preferences to show up as a temporary banner that vanishes on its own, or an alert that must be clicked to dismiss.

Do not disturb

 Know how to unsubscribe from web push notifications  here.

A history of Apple's push notifications

With the opening of App Store in 2008 to developers, Apple announced it would be setting up a centralized Push Notification Service as a mechanism for allowing apps to respond to updates from outside services without needing to remain active in the background, constantly listening and using the battery.

In addition to greatly lowering the iPhone's battery consumption compared to the prevailing background software model used by BlackBerry and Microsoft's Windows Mobile, Apple also used its new push notification system to power MobileMe's push messaging features.

However, Apple greatly underestimated the overwhelming demand for both apps and push notifications, sending the company back to the drawing board and delaying the rollout of Push notifications until iOS 3.0, after a stress-testing beta program involving the Associated Press and other app developers.

In late 2009, Google, a major iOS developer,  filed a patent  for "notification of mobile device events," describing a feature it would later add to Android, albeit without a security model like Apple's. This resulted in both an  adware/spam plague  for Android users, but also bragging rights for Android enthusiasts who can now claim Apple simply copied its Notification Center from Android rather than having laid all the groundwork for touchscreen smartphones, a functional app store and secure, battery efficient notifications system.

In 2010, Apple brought push notifications to the Mac as an API, initially to support FaceTime notifications and then more broadly as a public API in 2011's OS X Lion.

Notification Center (above) appeared on the Mac as an end-user-facing feature in OS X Mountain Lion last year (pictured above), after first making an appearance on Apple's mobile devices in iOS 5 the previous year.

You can very easily choose whether notifications appear as banners, alerts, or not at all. You can also choose to show them on the lock screen and decide how many recent items appear in the Safari Notification Center.

Shrikant Kale

Lists by Topic

• Browser Push Notification (82)
• Publisher Strategies (43)
• iZooto Updates (42)
• Push Notifications (30)
• audience development (23)
• wordpress (23)
• wordpress plugins (18)
• ad tech (11)
• audience engagement (11)
• App push notifications (8)
• Messenger Push Notifications (5)
• web push notifications (5)
• iOS push notifications (3)
• Android push notifications (2)
• Website Monetization (2)
• content management (2)
• Spotlight (1)
• audience retention (1)
• best seo plugins (1)
• iZooto Updates (1)
• startups, startup culture (1)

Get More Stuff Like This In Your Inbox

Stay up-to-date on topics of your interest. Subscribe now to join 10,000+ marketers who receive high-quality articles every fortnight.

Join The List!

Subscribe to join our list of 10,000+ marketers and receive high-quality articles on topics of your interest in your inbox every fortnight

Related Posts

Internal linking best practices for news websites.

News websites are constantly updated with fresh content- ranging from [...]

• Sanjay Kumar
• Apr 15, 2024

5 Ways Publishers Can Monetize Newsletters

Newsletters are owned channels that allow publishers to reach their au[...]

• Vaishnavi Ramkumar
• Apr 03, 2024

Diversify Revenue Streams: 5 Monetization Alternatives for Media Publishers

There are around nine different monetization options considered as the[...]

• Mar 27, 2024

• Steller Subscription Experience
• Audience Engagement Guide
• Content Engagement
• Website Engagement Tools
• Web Push Notifications Guide
• Messenger Push Notifications Guide
• App Push Notifications Guide
• Push Notification Marketing
• Push Notifications Examples
• Best Time To Send Push Notifications
• Understanding Your Audeince
• Engaging Your Audience
• Push Notifications Advertising Guide
• Overcoming Monetization Challenges
• Checklist For Push Monetization
• Monetization Strategies
• Dynamic Paywall
• Best Paywall Solutions
• Exit-Intent Recommendations
• Show Latest
• Magic Notifications
• Segmentation
• Personalization
• RSS Automation
• Web Push Notifications
• Messenger Push Notifcations
• App Push Notifications
• Email Newsletter
• On-Site Interactions
• iZooto vs OneSignal
• iZooto vs Feedify
• iZooto vs Push Engage
• iZooto vs SendPulse
• iZooto vs Aimtell
• iZooto vs Pushnami
• iZooto vs Pushly
• Switch To iZooto
• Success Stories

• Testimonials
• Comscore Partner

© 2023 Copyright iZooto. All rights reserved. 

• Copyright Terms
• Privacy Policy

Search code, repositories, users, issues, pull requests...

Provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

safari-push-notifications

Here are 2 public repositories matching this topic..., lahiiru / browser-push.

Complete workout and guidelines to add web push notifications support for your webapp without third-party notification provider

• Updated Apr 14, 2023

sohelamin / safari-push-notification

Push notification implementation for safari browser

• Updated Mar 30, 2019

Improve this page

Add a description, image, and links to the safari-push-notifications topic page so that developers can more easily learn about it.

Curate this topic

Add this topic to your repo

To associate your repository with the safari-push-notifications topic, visit your repo's landing page and select "manage topics."

Safari switches to Web Push protocol for Browser Notifications from Safari 16 and above

Safari now supports Web Push API for Browser Notifications

Apple’s Safari browser on MacOS has finally switched to the cross browser Web Push Notifications spec followed by Chrome, Firefox, Edge, Opera and other browsers. The change comes to Safari 16 on MacOS 13 (Ventura) or later. Essentially, you won’t require an Apple Developer account to send notifications to Safari anymore.

Till now Safari used Apple’s own proprietary APNS (Apple Push Notification Service) for enabling browser notifications for websites on MacOS. This required creating your own Web Push certificate to be able to accept subscribers and send notifications. While all other browsers used the cross-browser web push spec using VAPID protocol.

Finally Safari has made the switch and will use the established VAPID protocol for subscriptions and push notifications. This further suggests that Apple will be using the web push spec for notifications on iOS as well which is due to arrive in early 2023 .

We should be seeing the first beta with web push notification support for iPhones and iPads by the end of October or early November. For now, you do not need to make any changes to your integration or website.

PushAlert will handle the changes at the backend with Safari 15 and below using the old APNS protocol for push notifications, while users on Safari 16 and beyond will be switched to the web push spec for notifications.

If you have any questions or need any help, please reach out to us on chat or create a support ticket.

Don’t forget to sign up for PushAlert to be among the first ones to get web push notifications support on iOS.

Related Posts:

• Recent Posts

• Apple Reverses Decision: Will Continue To Support Home Screen Web Apps in the EU - March 11, 2024
• Introducing Onsite Messaging by PushAlert for Shopify: Boost Customer Engagement and Drive Conversions - June 14, 2023
• Google Chrome on iOS now supports Web Push Notifications with Version 113 - May 12, 2023

Recommended

• 5 Ways to Boost Web Push Notification Subscription Rate
• Audience Segmentation is the Key to Drive Conversions with Push Notifications
• 5 things you can do to improve Push Notifications
• Increase your sales, engagement with Web Push Notifications
• Increase Engagement in Push Notifications with Action Buttons
• Chrome Push Notifications
• Firefox Push Notifications
• Push Notifications for WordPress
• Push Notifications for Joomla
• Mobile Push Notifications
• Javascript API
• Terms & Conditions
• Privacy Policy
• Notification Preferences

PushAlert is a user engagement, retention and marketing automation platform which allows you to push real-time notifications to your website users on both mobile and desktop.

© Copyright 2024 InkWired. All rights reserved.

Notification Programming Guide for Websites

• Table of Contents
• Jump To…
• Download Sample Code

Configuring Safari Push Notifications

In OS X v10.9 and later, you can dispatch Safari Push Notifications from your web server directly to OS X users by using the Apple Push Notification service (APNs). Not to be confused with local notifications, push notifications can reach your users regardless of whether your website or Safari is open.

To integrate push notifications in your website, you first present an interface that allows the user to opt in to receive notifications. If the user consents, Safari contacts your website requesting its credentials in the form of a file called a push package . The push package also contains notification assets used throughout OS X and data used to communicate to a web service you configure. If the push package is valid, you receive a unique identifier for the user on the device known as a device token . The user receives the notification when you send the combination of this device token and your message, or payload , to APNs.

Upon receiving the notification, the user can click on it to open a webpage of your choosing in Safari.

Registering with Apple

You are required to register in the Certificates, Identifiers & Profiles section of your developer account to send push notifications. Registration requires an Apple developer license . For more details on registering with Apple, see Developer Account Help .

When registering, include the following information:

Identifier . This is your unique reverse-domain string, such as web.com.example.domain (the string must start with web. ). This is also known as the Website Push ID.

Website Push ID Description . This is the name used throughout the Provisioning Portal to refer to your website. Use it for your own benefit to label your Website Push IDs into a more human-readable format.

The registration process looks like the form in Figure 2-1 .

After you have successfully entered this information, the certificate you use to sign your credentials and to push notifications becomes available to download.

Certificate Revocation

To protect OS X users, Apple reserves the right to revoke your certificate if you abuse the push notification service or fail to adhere to Apple’s guidelines . Certificate revocation results in the inability to issue new push notifications.

If your push certificate has been compromised, you can manually revoke it from Apple’s servers in the Certificates, Identifiers & Profiles section of your developer account, located at https://developer.apple.com/account .

Building the Push Package

When a user is asked for permission to receive push notifications, Safari asks your web server for a package. The package contains data that is used by the notification UI, such as your website name and icon, as well as a cryptographic signature. The signature verifies that your notification hasn’t been intercepted by a man-in-the-middle attack and that it is indeed coming from a trusted source: you.

You create the push package by first populating a folder with a specific set of files. The push package contains a website JSON dictionary, a set of icons (referred to as an iconset ), a manifest, and a signature. Listing 2-1 exemplifies the complete push package file structure.

Listing 2-1   File structure of a push package

After the required files are in place, compress the folder into a ZIP archive to create the finalized push package. The push package is a static file that should live on your server. Return the push package from your web server in the location you specify in Downloading Your Website Package .

The Website JSON Dictionary

The website JSON dictionary named website.json contains metadata used by Safari and Notification Center to present UI to the user and to communicate with your web service.

The keys of the website JSON dictionary shown in Listing 2-2 are described in Table 2-1 .

Listing 2-2   A sample valid website.json file

The Iconset

The iconset is a directory called icon.iconset that contains PNG images in varying sizes. The images in your iconset populate the icons displayed to the user in the permission prompt, Notification Center, and the notification itself. Because your icon is static, it is unnecessary to include it in every push notification. Instead, your icons are downloaded once from your server and stored on the user’s computer. Icons in the icon set are named with the convention shown in Listing 2-1 with the dimensions each name implies.

The Manifest

The manifest is a JSON dictionary named manifest.json that contains an entry for each file, where the local file path is the entry’s key, and a dictionary object is the entry’s value. This dictionary contains the hashType and hashValue , which is the file’s SHA512 checksum; for example:

Every file in the package must appear in the manifest, except for the manifest itself and the signature. Each key and value must be a string and a dictionary, respectively.

To manually generate a SHA512 checksum, type shasum -a 512 <filepath> in a Terminal prompt. The create_manifest function in the attached createPushPackage.php companion file (the link is near the top of the page) iterates through each file and generates a checksum for you.

The Signature

The signature is a PKCS #7 detached signature of the manifest file. Sign the manifest file with the private key associated with your web push certificate that you obtained while registering with Apple. In PHP, you can do this with the openssl_pkcs7_sign function. The create_signature function in the attached createPushPackage.php companion file (the link is near the top of the page) shows how you can do this.

If the contents of your push package ever change, you’ll need to recompute your signature.

Requesting Permission

There are two important JavaScript functions to keep in mind when dealing with push notifications. The first is a lightweight function that checks the user’s permission level without talking to the server. The second contacts with the server and displays the permission dialog to the user, as shown in Figure 2-2 .

To check the permission level a user has set for your website, call window.safari.pushNotification.permission() with your Website Push ID as an argument. This synchronous call returns a permission object for the given identifier by looking in the user’s preferences. This function does not contact your server.

The permission object contains the keys as described in Table 2-2 .

To request permission to send the user push notifications, call window.safari.pushNotification.requestPermission() . Requesting permission is an asynchronous call.

A description of each argument is as follows:

url —The URL of the web service, which must start with https . The web server does not need to be the same domain as the website requesting permission.

websitePushID —The Website Push ID, which must start with web. .

userInfo —An object to pass to the server. Include any data in this object that helps you identify the user requesting permission.

callback —A callback function, which is invoked upon completion. The callback must accept a permission object with the same structure as described in Table 2-2 .

Listing 2-3   Handling permissions for website push notifications

Configuring Your Web Service Endpoints

When a webpage requests permission to display push notifications, an HTTP request for your credentials is sent to your web server. Similarly, when a user changes their website push notification settings in Safari or System Preferences, an HTTP request is sent to your web server. You need to configure a RESTful web service on your server to respond to these requests accordingly. The web service does not need to be hosted on the same server(s) or domain(s) that serve your webpages.

To properly implement the web service, craft your endpoints as specified in the following sections using the URL fragments listed in Table 2-3 .

Downloading Your Website Package

When a user allows permission to receive push notifications, a POST request is sent to the following URL:

This POST request contains the following information:

In the HTTP body . The same user info JSON object that is passed as the third argument of the requestPermission() call. Use the user info dictionary to identify the user.

When serving the push package, return application/zip for the Content-type header.

Registering or Updating Device Permission Policy

When users first grant permission, or later change their permission levels for your website, a POST request is sent to the following URL:

In the HTTP header . An Authorization header. Its value is the word ApplePushNotifications and the authentication token, separated by a single space. The authentication token is the same token that’s specified in your package’s website.json file. Your web service can use this token to determine which user is registering or updating their permission policy.

Respond to this request by saving the device token in a database that you can later reference when you send push notifications. Also, change the user’s settings in your database to the values indicated by the parameterized dictionary for the device.

If you have an iOS app that sends push notifications, and users log in to your app with the same credentials they use to log in to your website, set their website push notification settings to match their existing iOS push notification settings.

Forgetting Device Permission Policy

If a user removes permission of a website in Safari preferences, a DELETE request is sent to the following URL:

This DELETE request contains the following information:

In the HTTP header . An Authorization header. Its value is the word ApplePushNotifications and the authentication token, separated by a single space. The authentication token is the same token that’s specified in your package’s website.json file. Your web service can use this authentication token to determine which user is removing their permission policy.

Use this authentication token to remove the device token from your database, as if the device had never registered to your service.

Logging Errors

If an error occurs, a POST request is sent to the following URL:

In the HTTP body . A JSON dictionary containing a single key, named logs , which holds an array of strings describing the errors that occurred.

Use this endpoint to help you debug your web service implementation. The logs contain a description of the error in a human-readable format. See Troubleshooting for a list of possible errors.

Pushing Notifications

You send push notifications to clients in the same way that iOS and OS X apps push notifications to APNs. As a push notification provider, you communicate with APNs over a binary interface. This a high-speed, high-capacity interface uses a streaming TCP socket design with binary content. The binary interface is asynchronous.

The binary interface of the production environment is available through gateway.push.apple.com , port 2195. Do not connect to the development environment to send Safari Push Notifications. You may establish multiple parallel connections to the same gateway or to multiple gateway instances.

For each interface, use TLS (or SSL) to establish a secured communications channel. The SSL certificate required for these connections is the same one that’s provisioned when you registered your Website Push ID in your developer account. To establish a trusted provider identity, present this certificate to APNs at connection time.

A JSON dictionary like the one in Listing 2-4 produces a notification that looks like the one in Figure 2-3 . The JSON object must strictly conform to RFC 4627 .

Listing 2-4   A JSON dictionary showing a sample notification payload

The outermost dictionary, which is identified by the aps key, should contain another dictionary named alert . The alert dictionary may contain only the keys listed in Table 2-4 . Custom keys are not supported.

The url-args key specifies an array of values that are paired with the placeholders inside the urlFormatString value of your website.json file. The url-args key must be included. The number of elements in the array must match the number of placeholders in the urlFormatString value and the order of the placeholders in the URL format string determines the order of the values supplied by the url-args array. The number of placeholders may be zero, in which case the array should be empty. However, it is common practice to always include at least one argument so that the user is directed to a web page specific to the notification received.

For a low-level breakdown of notification packets, as well as a code listing of how to send a notification over a binary interface, read Provider Communication with Apple Push Notification Service in Local and Remote Notification Programming Guide .

Troubleshooting

If something goes wrong in downloading your push package or delivery of your push notifications, the logging endpoint on your web service as described in Logging Errors will be contacted with an error message describing the error. Table 2-5 lists the possible errors and steps you can take to fix them.

Also check Web Inspector for errors that might occur in your JavaScript. To learn how to use Web Inspector, read Safari Web Inspector Guide .

Copyright © 2018 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2018-04-09

Sending feedback…

We’re sorry, an error has occurred..

Please try submitting your feedback later.

Thank you for providing feedback!

Your input helps improve our developer documentation.

How helpful is this document?

How can we improve this document.

* Required information

To submit a product bug or enhancement request, please visit the Bug Reporter page.

Please read Apple's Unsolicited Idea Submission Policy before you send us your feedback.

Build scalable realtime features

Programmatic push notifications

Read the docs to learn how to use our products

Explore our tutorials to build apps with Pusher products

Reach out to our support team for help and advice

Get familiar with Pusher-specific terminology

• User stories

How we built push notification delivery for Safari users on Beams

Delivering push notifications to Safari is very different to other browsers. Find out how we implemented Safari support for Pusher Beams.

Introduction

In 2020, we added web browser support to Pusher Beams , enabling notification delivery to Chrome, Firefox, Edge and Opera . Safari was missing from this list, but we have recently released beta support so that you can send Safari push notifications to your users with Beams.

Implementing Safari support required significant additional development work compared to the other browsers, and in this blog post we will discuss the differences between sending notifications to browsers using the Web Push API and Safari.

The vast majority of browsers support the Web Push API (including Chrome, Firefox, Edge and Opera). If you implement support for this web standard then you will be able to send notifications to most desktop browsers – and many browsers on Android. You don’t have to add anything to your code to support specific browsers.

Safari on macOS does not support the Push API and instead Apple opted to develop their own push notification implementation which is closer to the notification experience of a macOS app. It uses Apple’s push notification gateway, APNs, which will be familiar to those who develop apps for iOS and macOS. Note: Safari on iOS doesn’t support any kind of browser notification at all, and that’s the same for all third party browsers on iOS.

While there are a lot of similarities when it comes to user experience, there are key technical differences in implementing Safari support, the most significant being the steps you have to take when registering for notifications and the actions you can take upon receiving a notification.

Registering for push notifications

The Push API centers around service workers . First, you must register a service worker for your web app. You can then request notification permission from the user, passing your VAPID public key from your sever (see below). You then get credentials back that you can pass to your server to use when sending notifications.

VAPID keys are essentially a public and private key pair generated on your server and are used as part of the VAPID specification, which allows the push gateway to verify your server’s identity. The public key is passed to the browser in order to tie each subscription to your key, so only you can publish notifications to those users. The keys never expire and are free to generate.

Safari doesn’t use service workers for push notifications. When requesting notification permission in Safari, you pass the URL of your web service. You must implement the web service with a number of specific endpoints which Safari will automatically make requests to during the registration process. Safari uses these endpoints to:

• Request the “push package”
• Notify your server of new subscribers/removed subscribers
• Log errors regarding the push package and registration process

A push package is a zipped directory containing your web app’s icon in several sizes, plus a JSON file containing details about your web app. You must cryptographically sign the files using a certificate obtained from Apple (see below). This zip file is downloaded by Safari every time the permission dialog is shown. We found the implementation of the web service and push package generator to be the most complicated part of adding Safari support to Beams. It is completely different to the Push API and therefore there wasn’t much code to be reused from our Push API (or iOS) implementation.

You must use an Apple-issued certificate to sign push packages and authenticate when publishing notifications to Safari. The certificate proves ownership of an identifier for your web app called a “website push ID”. To register a “website push ID” you must have a paid Apple Developer program membership. The certificate expires after a year and therefore requires yearly renewal.

It is possible to publish Safari notifications using an authentication token signing key rather than a certificate, which is desirable because the key never expires. However it is still necessary to use the certificate when signing push packages and as a result we have to ask customers for their certificate for Safari, rather than their key.

Interacting with/responding to notifications

The Push API notifies the service worker when a new notification is received. This allows you to execute JavaScript in response to the notification, which can utilize any included data. For example, you could update your webpage to show an icon indicating a new message was received. We use this functionality to implement Pusher Beams insights features, such as delivery and open tracking.

Safari doesn’t use service workers and it isn’t possible to execute any code in response to receiving a notification. This means it wasn’t possible for us to implement delivery tracking for Safari browser notifications. However we do have some ideas for future changes to support open tracking.

For Push API notifications, the developer generally has more control over what happens when a notification is clicked. For example, it is possible to just hide the notification. Safari on the other hand is more limited when it comes to notification functionality, and always requires a URL to be opened when a notification is clicked.

Displaying Safari notifications

Visually, notifications displayed by Safari are slightly different compared to other browsers on a Mac.

Notifications delivered via the Push API are displayed as a “sub notification” of the browser.

Whereas notifications delivered to Safari appear like a standalone Mac app and are grouped together in the Notification Center as such.

On a Mac, Safari notifications are delivered when the browser is closed, whereas Push API browsers only appear to deliver notifications when the browser is running (but the page does not have to be open).

There is less customization available for Safari notifications compared to Push API notifications (and iOS notifications). For example, it isn’t possible to include an image in a Safari notification, other than your web app’s icon. This means we aren’t able to offer rich notifications for Safari in the same way we can for mobile apps or other browsers.

Apple have not updated Safari notifications for a long time. We’d love to see richer notification opportunities for Safari users in the future so that we can offer the same notification experience across all browsers we serve. We’ll be sure to stay on top of any new customization functionality should it arise

There are many differences when sending notifications to Safari compared to Push API browsers. Implementing Safari support was a surprisingly complicated process: we found there to be little overlap between the Push API and Safari in terms of our internal implementation.

The good news is that Pusher Beams now has Safari support and we’ve been able to hide most of the complexity for developers by:

• We provide a unified API for triggering notifications to Push API browsers and Safari – you can send to both with a single API call (as well as to iOS/Android)
• We provide a single client SDK that supports Chrome, Firefox, Edge, Opera and Safari.
• We hide all the complexity of generating and serving push packages, including the resizing of icons.
• We store your credentials and manage browser tokens
• We handle the nuances of publishing to APNs at scale

You can read about how to get started with Pusher Beams and give feedback on the beta program here .

• Contact Sales
• Terms & Conditions
• Cookie Policy
• Privacy Policy
• Code of Conduct

© 2024 Pusher Ltd. All rights reserved. Pusher Limited is a company registered in England and Wales (No. 07489873) whose registered office is at MessageBird UK Limited, 3 More London Riverside, 4th Floor, London, United Kingdom, SE1 2AQ.