In the last WebRTC Standard Update provided by Dan Burnett and myself we talked about the work done in W3C and IETF for standardizing push notification.
Time to put standards aside and look at what is currently available by the industry.
In mobile, life is pretty simple. The major vendors (i.e. Google and Apple) provide push notification services for their mobile OS. An application can receive user permission for sending push notification messages and using the respective vendor’s push notification server send notifications to the user.
In WebRTC context, since most of the use cases on mobile opt for an application and not browser, the mobile push notification is sufficient.
In PC and Mac the situation is different, the common usage of WebRTC is in the browser. As stated in the standard update:
it doesn’t make sense to have a notification service per web application, but rather solve the problem in a way similar to how notifications are done on mobile, e.g., in the OS level or through a limited number of push notification servers that would consolidate all notifications.
Let’s see what is currently available.
Push notification for OS X
Apple offers 2 types of notifications for OS X (Mac).
The first and less interesting one is Local Notifications. These notifications are part of Safari and are relevant only for the time a user is on your website. At that time, the website can send notifications to the user but once the user exists the website, Local Notifications can’t be sent and those already sent will disappear.
The Apple Local Notifications mechanism is based on W3C WHATWG.
The other type of notifications Apple offers is Push Notifications. As of OS X Mavericks,
Apple started utilizing its push notification service built for iOS also for OS X.
This means that a native application released through the OS X App Store can leverage APNs (Apple Push Notification Service). And send notifications to Mac users similarly to how this is done for iOS devices. One variation of this is Push Notifications for Websites.
Since Safari is an application running in OS X, Apple introduced Safari Push Notifications. It allows websites to ask the user for permission to send him notifications. Clicking on such a notification will launch Safari (if not open) and take the user to the URL associated with that notification.
If it wasn’t obvious until now, this push notification mechanism is Apple proprietary and is not built according to W3C or IETF standards.
Apple Push Notifications and WebRTC
Since Apple Push Notifications for Websites is tightly coupled with Safari it doesn’t really help much for WebRTC as long as Safari doesn’t support WebRTC (I’m ignoring the plugin option).
Theoretically, Google and Mozilla could provide Chrome and Firefox as an application through the OS X App Store and use the Apple APNs system but that is probably a stretch, at least for Google.
Push notifications for Windows
Microsoft offers push notifications service for its mobile operating system but currently this service is not available for desktops.
Microsoft will launch Windows 10 to the public in July 2015. This new Windows version will run across all Microsoft devices, desktops, laptops, tablets, smartphones, and any other Microsoft device.
While not clear yet, my guess is that we will see push notifications being part of the OS and used across all devices. This version will also come with the new browser named Spartan, hopefully Windows 10 will also bring WebRTC to the Microsoft browser.
Push Notifications for Chrome
While Google offers push notification service for Android, Chrome 42 takes this powerful tool one step further (thanks to Tsahi for alerting me on this addition) as it introduces push notifications for the browser in both Android and desktops.
The Chrome push notification is using the W3C Push API and Service Worker specifications.
A service worker is a script run by the browser in the background, it is not related to a specific web page but rather serves multiple web pages. This means that a webpage can send the user push notification messages even when the user is not visiting the website. To know current support for service worker on the different browsers check out the site Is Service Worker Ready.
Chrome Push Notifications and WebRTC
In context of WebRTC, this means that if a user asked to be contacted by a live agent, the website can alert the user an agent is now available and make the WebRTC call to him even if the user is not visiting that website anymore. Limitation is that the browser itself needs to be running, a limitation that doesn’t exist when push notification is done in the OS level.
Push Notifications for Firefox
Mozila also provides push notifications service for Firefox OS and the Firefox browser. As stated by Mozila, this implementation is not part of the W3C spec.
Firefox Push Notifications and WebRTC
Mozila lists several use cases it envisions for push notifications; one of these use cases is WebRTC on desktop browsers.
Why this is important?
In many WebRTC use cases I hear about from customers, the need to alert the user is a mandatory requirement. They are looking for WebRTC Push Notifications services. With the current work being done in the standards along with the actual implementations already available, it looks like this requirement is going to be satisfied. This work is not specific to WebRTC in any way, it is a result of a generic need for increasing user engagement to websites, similar to how this is done in mobile applications.
[…] Push Notifications Services You Can Use Today for WebRTC […]