Sign up

Why You Don’t Really Need to Build React Web Notifications for Your App

Allie Dyer Bluemel

Last updated on

A custom React web notification system can be a beast, especially if your product is spread across a web app and a mobile version of the site. If you choose to build a custom solution, fixing one-off problems and bugs with browser and device compatibility of the React app can set you back on precious time with other tasks.

Before implementing a custom solution, it's imperative to know how much work and maintenance will go into it. You don't want another tedious and time-consuming system to take care of in your codebase.

Support and implementation of various notification APIs differ between devices and browsers, so choosing a third-party solution to take care of these inconsistencies can be a smart choice.

Building your own React web notifications comes with hassles

Getting started with the Notifications API is fairly straightforward, and with support for all modern desktop browsers (sorry Internet Explorer) and support for Chrome and Firefox on Android, it can be a good solution to get up and running.

But if your strategy heavily relies on support for iOS's Safari, which doesn't support the Notifications API, this is something to consider. The appeal of the Notifications API is that you can send push notifications to your users even if they've switched to a different tab or web app.

To get started with the Notifications API, you need to check whether the user's browser supports it and then request notification permission. Building a basic support check and permissions request into your React web notification system might look something like this:


componentDidMount() {
   if ('Notification' in window) {
      //API supported
   } else {
       //API not supported

The requestPermission method is promise-based and can be entered into Chrome's console to show you the little white notification box:

Notification.requestPermission().then(function(permission) {})

And here's where some compatibility issues arise. If we test this method in Safari, it will throw an error.

Safari doesn't support the Notification promise, and instead still uses the deprecated callback method:


This means we need to create a secondary check and permissions request for Safari in our lifecycle method.

And because notification requests have become quite spammy, in January 2020, Chrome introduced the quieter permission UI, and Firefox introduced something similar with their version 72 update. Having your push notification blocked is as simple as people consistently saying no to it. This results in your notification permission requests getting blocked from your web app altogether for the user.

To manage user notification subscriptions, you need to register service workers. A service worker runs separately from the main browser thread and can push notifications to users. The Notifications API has several additions to the Service Worker API:

While Safari desktop and iOS versions support the Service Worker API, as we've noted, Safari on iOS isn't compatible with the Notifications API. In addition, no version of Safari supports the Push API . The Push API can be implemented to send web push notifications to users even if your web app isn't loaded.

To achieve push notifications even when the web app isn't loaded, Safari provides its own solution for desktop users. If you want to implement desktop notification with the Push API, you need to take into account having a separate implementation for Safari desktop.

Third-party solutions for your React web notifications take care of the hassles

The implementation of a third-party tool over a custom solution for your React app gives you access to a continuously maintained notification system with other added benefits. The inconsistencies with browser support can be a pain to build, manage, and maintain. Third-party tools and SDKs can handle those hassles for you, leaving you to focus on implementation and much lower maintenance.

Let's take a look at how third-party SDKs and segmentation solutions can aid your React web notification journey.

SDKs and solutions for Safari

Third-party tools will give you options to integrate a variety of SDKs and setups in your React app. If you change your tech stack down the road, there might be some time-consuming tasks with overhauling some or all of the notification systems.

But doing so with a third-party tool won't be as bad as overhauling a custom-built solution. A tool like OneSignal has an SDK for push notifications on Chrome, Firefox, and Safari desktop. Special instructions for Safari include setting up a safari_web_id that give you a Safari Web Push Certificate:

<script src="" async=""></script>
 window.OneSignal = window.OneSignal || [];
 OneSignal.push(function() {
 appId: "8e04addd-be31-43dc-8c7a-0618eb781972",
 safari_web_id: "",
 notifyButton: {enable: true,},});});

With a third-party tool, you'll probably also find SDKs and setups for other specific needs, like mobile push on iOS, Android, Amazon, Drupal, and Wix.

Additional features, Like Built-in Segmentation

If your notification system starts being really successful, there will be additional asks-like segmenting users. Segmenting notifications allows for more meaningful communication between the product and your users. Instead of sending everyone everything (and probably annoying them), segmenting will keep the perception of spammy push notifications low.

SendPulse is a third-party tool that offers segmentation for web push notifications in a variety of ways. With the ability to separate users into groups by browser language or browser type, region, and subscription info, you can target groups for specific push notifications.

Beyond basic segmentation, Gravitec is a third-party tool that offers segmentation custom tags and personal identifier aliases. Each user will have a single alias assigned to them, but with the ability to attach multiple tags, allowing you to target them with very specific notifications.

Building custom segmentation is another daunting process in a roll-your-own notification solution. Third-party tools have these features available as soon as you get set up, and they even allow non-devs a way to see and interact with segments through user interfaces.

Your time is valuable—spend it on core features

Looking beyond the limitations of various APIs and browser compatibility, the time suck of building a notification system for your React app can't be overlooked. A very basic notification system might not seem like a big ask, but as notifications become a successful strategy for the product, the notification structure will have to grow.

Beyond a basic notification system, requests for segmentation, translations, managing subscriptions, and A/B testing will eat up your time. Data from The New Stack shows developers spend only 32% of their time improving on or writing new features. A notification system is likely to be a never-ending project, and it's a huge ask for a team whose main focus is not notifications.

Improving core features and writing new features that move the core business forward should be what you focus your time on as a developer. With a third-party notification solution, you can offload a lot of the behind-the-scenes work to non-devs through GUIs. Marketing teams can take control over segmentation and tags, so you don't have to stop what you're doing to update the notification system with every new request.

Anytime you can offload work to non-devs is a good time. 😉

React notifications with MagicBell

With a focus on engaging and notifying users in their workflows, MagicBell is a notification solution that can integrate into your product in less than an hour.

With features that give users an overview of unseen notifications while they are away and one-click solutions to find relevant action items, they can get back on track.

A React SDK and a free plan that includes web push, in-app, and email notifications mean there's no need to build your own React web notification solution.

Sign up for a free trial now.

Related articles: