Push Notifications

Every other messaging pattern we've covered assumes the user is actively connected to your application. Polling, long polling, webhooks, they all require an open connection or an active session.

But what about when the user has closed your app? When their phone is in their pocket, their laptop is asleep, or they switched to a different browser tab three hours ago?

That's where push notifications come in. They're the one messaging pattern that can reach users even when they aren't actively using your product.

Uber sends you a push when your driver arrives. WhatsApp sends one when you get a message. YouTube sends one when your favorite creator uploads. Duolingo, well, Duolingo sends them when you haven't practiced, when you almost practiced, when someone you've never met practiced, and when the owl is disappointed in you.

Push notifications are absurdly powerful for engagement. They're also absurdly easy to abuse. The companies that get them right see 3-10x higher retention. The companies that get them wrong get uninstalled.

Push notifications aren't one technology. They're three separate ecosystems that happen to serve the same purpose:

Mobile push (APNs + FCM):

• Apple Push Notification service (APNs) for iOS devices
• Firebase Cloud Messaging (FCM) for Android devices
• Your server sends the notification to Apple/Google, who deliver it to the device
• Works even when the app is closed or the phone is locked

Web push (Web Push API):

• Works in browsers (Chrome, Firefox, Edge, and Safari since 2023)
• Uses a service worker that runs in the background
• Your server sends to a push service (browser-specific), which delivers to the browser
• Works even when the tab is closed (as long as the browser is open)

The flow is the same for all three:

1. User grants permission (critical. You get one chance to ask.)
2. The device/browser registers with its push service and gets a unique token
3. Your server stores that token
4. When an event occurs, your server sends the notification payload + token to the push service
5. The push service delivers it to the user's device

One design choice explains all three ecosystems. If every app maintained its own persistent connection to its server, a phone with 50 apps would need 50 open connections, destroying battery life. Instead, the device maintains a single connection to Apple or Google's push service, which multiplexes notifications from all apps over that one connection. Battery life stays reasonable. Your server talks to the push service, never directly to the device.