Most of the features and APIs we have seen in the mobile world are now available in the web as well. That rich set of web APIs is making Progressive Web Apps (PWAs) a great alternative; if not a replacement, to most mobile app experiences out there.
An empowered and rich web makes PWAs the most cost-effective way to engage with your audience when compared to traditional mobile apps. With PWAs you have one single codebase using one single set of APIs that you can continuously deliver and run everywhere.
An effective way to get users to engage with your PWA is through Web Push Notifications.
Once the user has opted-in, Web Push Notifications allows them to receive relevant and customized updates. This helps to bring them back to your PWA; effectively re-engaging with them.
Web Push Notifications opens a new set of possibilities and works through a combination of Web APIs:
The WHATWG Notification API 1 has been adopted by most modern browsers, the only exception is iOS Safari which doesn't support it at all.
Chrome for Android supports notifications via the Push API but not the Web Notifications API.
Can I Use notifications? Data on support for the notifications feature across the major browsers from caniuse.com.
The W3C Push API 2 is still a working draft but has been adopted by most modern browsers, except for desktop Safari because it has its own custom implementation, and iOS Safari which has no support at all.
Can I Use push-api? Data on support for the push-api feature across the major browsers from caniuse.com.
To be able to use the Notification API and display system notifications, permission must be requested and granted by the end user.
The current permission status can be checked at any point using
Notification.permission or requested using
The possible results for both are either
default ; the latter meaning that the permission status is unknown; possibly because it wasn't asked yet - effectively acting as
Check permission status:
Though this seems like a fairly straightforward process, only a few API calls; take note! If your user denies the permission to receive notifications, this decision is permanent and you won't have a second chance to ask for it.
So rather that just asking permission as soon as the user lands in your PWA, do it at a more opportune moment, when the user is more open to accepting, for example when they interact or request something from within your app.
Once permission has been granted by the user, it is quite simple to build and display a notification. Choose a title, a few other optional properties and click handler and the notification is displayed immediately.
It is possible to send push notifications to the user regardless of the web app being in the foreground or even currently loaded.
To achieve this a service worker must be active and must subscribe to push notifications using
This function returns both an endpoint and the encryption key needed for the server to push data.
After this setup step, the service worker is ready to receive pushed data by listening to a
Main client code
Web Push Notifications is another of many new APIs that is closing the gap between web and mobile development.
Unfortunately Safari is lagging a bit behind on these specific APIs, most likely because it breaks Apples mobile app business.
It's ironic that even though Google coined the term, PWAs were actually envisioned by Steve Jobs and first announced back in 2007 WWDC during one of his one more thing moments. The original way to develop apps for the iPhone was based on web technologies and not proprietary SDKs.
Apple moved forward by adding support to Web Workers in Safari, lets hope they keep the pace and help make the web the best platform to build apps.
If you need help setting up your PWA or want to learn more about it, get in touch with us at NearForm .
This is the last post of our series on PWAs, other articles can be found in our blog here: