The Emerging War Over Desktop Push Notifications

Page 2 - By Any Other Name

But it’s something of a misnomer to reduce Apple's solution to "browser push" or even "desktop push." In point of fact, Apple gifted the Web with OS X push because the Notification Center is built into the Finder, not the browser. Put differently, it’s not necessary that Safari be active for a notification to be received. When a message is clicked, the browser opens and the URL associated with the notification instigates a new tab.

This is in stark contrast to earlier browser push technologies, like WebSockets, which require that the tab for a website remain open for the communication channel to persist. And although similar in appearance to Growl Notifications, Apple’s Web push does not require the installation of any software by the user - a critical advantage so far as user adoption is concerned.

Chrome and Firefox, are taking a more straightforward approach, and will require the browser to be open to function. To be honest, though, this is not much of an ask. Users often keep their browser of choice open all the time with dozens of tabs and a handful of windows active.

Challenges for Non-Engineers

Apple's Web push is problematic insofar as it’s difficult to integrate. The first hurdle is a $99/year Apple Developer Account, and the actual implementation can be described as labyrinthine. Even a seasoned developer familiar with all the moving parts will need a couple of weeks to get the most basic pieces working.

It isn’t surprising that third party solutions are emerging. For example, a Y Combinator backed startup named Roost provides a simple javascript solution (as well as plugins for WordPress, Drupal, and Shopify) as well as a metrics dashboard and advanced feature sets, such a geo-targeting, APIs, A/B testing, and audience segmentation capabilities.

That's my company, by the way. I'm one of three cofounders, and our focus is helping sites like TMO implement Apple's desktop push notifications.

Chrome and Firefox look to be somewhat easier to integrate, but supporting all simultaneously will probably push websites to third party solutions to get everything in one package with a bow on top.

Pushing the Envelope Further

At WWDC in June, we saw Apple continuing innovation in the notification space, both on mobile and desktop. The Notification Center got significant development attention in OS X (Yosemite). The Today feature integrates with other parts of the OS. Widgets can be added as well, allowing user customization. Both of these features make the Notification Center more central to the Apple experience. All of these things build on apple Web push experience for desktop.

Today in OS X Yosemite

On the mobile side of the equation, iOS 8 notifications got a lot of love from Apple’s development team, but they did not extend this love to mobile Safari. Web push is not present in the latest builds of iOS 8, and is not mentioned in the surrounding documentation.

And it looks like Chrome and Firefox will one-up Apple in this respect . Both plan to support Web push for mobile browsers - and in the very immediate future. The word on the street is that Chrome push notifications have a mobile release concurrent with the desktop solution.

Who Will Win the War?

Despite the competitive landscape of Web push, Apple is well-positioned to continue to lead the space. Much will depend on how quickly Apple supports push within its mobile browser. If Apple lets Google and Mozilla race ahead as the line between mobile and desktop blurs, then the company may find itself following, instead of leading. And this is all happening before the battle for Web push on desktop has even truly begun.

Some people love web push notifications, and others not as much. It’s an opt-in technology, so no one is forced to participate. The key to publishers is that the users who do opt-in to share really love it - and are far more active on social channels.

ftolar59, I too find most of them annoying and intrusive. I suppose that a work-around would be to turn on Do Not Disturb. Or perhaps go into the Notification Preferences and turn off individual items.

Unfortunately they can only be disabled individually in Safari Preferences. And only after accepting them first. If you click do not except when loading a site, they do not appear in Preferences. And the dialog returns every time you revisit the site. Apple obviously never considered that anyone would find this “feature” an annoyance. And with more and more sites adding this, I may eventually end up using another browser to avoid it.

I wish I could believe it will be for the better but from I’ve observed so far, I’m not hopeful. Nobody takes the time to consider all the angles. Slap it together and shove it out the door. Then blame the user if it doesn’t do what it was meant to. “You’re not holding it right.”

It would be nice if Apple’s were triggered by a Javascript call so that it only presents when the website has shown a friendly message describing what kinds of notifications the site wants to send. With TMO’s I had no idea so just denied it. I wouldn’t want a push on every article anyway, but I might want notifications for certain columns, topics, or authors.

Then if I say No I could go into my TMO account settings and click a button which would call the Javascript API to have Safari offer it to me again.

Mobile browser push would help reduce the need for a separate app for every content provider. The first iPhone wanted 3rd parties to use web apps with app icons created on the home screen to jump to that website. This could help bring us around full circle.

I guess I’m the odd man out - I have an RSS program running in the background so I get a ton of notifications from that but I only get handful of Safari Push notifications during that same time period (most are from TMO, which I don’t mind).

Running the FF beta I have yet to see any notifications, even for here. Any notice when they’ll migrate over?