Web Push escaped app-store silos by making sender identity standard

Early Web Push worked in Chrome, but the backend path still ran through Firebase Cloud Messaging and required Google-specific project credentials. That made the open API feel less open for developers serving more than one browser.

Chrome's 2016 interoperability note described the fix: FCM began accepting the standard Web Push Protocol, and VAPID supplied sender authentication with a public/private key pair instead of a GCM sender ID and proprietary Authorization header.

The practical result was one code path. Chrome's own guidance said VAPID meant developers no longer needed a Firebase project and could use the same subscription and send flow in Chrome and Firefox.

Apple's WebKit later joined the standards path in Safari 16 on macOS Ventura. WebKit said Web Push is enabled by Push API, Notifications API and Service Workers together, and that standards-compliant sites could reach Safari users without joining the Apple Developer Program.

Make push sender identity portable

It kept browser push decentralized: each browser could run its own service while apps used one protocol.

It replaced vendor registration with cryptographic identity carried in the request.

It aligned push with the web's permission model by requiring user-visible notifications.

A web standard wins when it removes the vendor signup step from the common path.

After VAPID, Chrome and Firefox shared the same standards-based sending path, and Safari added Web Push support in 2022. Web apps could notify users across major engines without building a native app solely for push.