Push notifications: how your phone buzzes for an app that isn't running

The puzzle

Your phone is in your pocket with the screen off. A friend sends you a chat message, and a second later the phone buzzes and shows it. Yet the chat app was not running. Who woke it up, and how did the message find your phone among billions?

The answer is a push notification: a small message that a company's server pushes to your phone, instead of the phone asking "anything new?" every few seconds. Asking constantly would drain the battery, so phones do something smarter.

One shared connection instead of one per app

If every app kept its own connection open to its own server, a phone with 80 apps would be busy all day. Instead, the phone's operating system (the main software that runs everything else) keeps one connection to a push service run by the platform's maker. On iPhones that is Apple's service, APNs (Apple Push Notification service). On Android phones with Google services it is FCM (Firebase Cloud Messaging). Every app on the phone shares that one connection.

When an app first asks for notifications, the operating system registers with the push service and hands the app a device token: a long string that works like a mailing address for that app on that phone. The app sends the token to its own server, and the server stores it next to your account.

The journey of one message

When your friend hits send, this happens:

1. The chat company's server looks up your device token. 2. It sends the push service a request containing the token and a small payload (the message content, written as JSON, a text format for structured data). 3. The push service finds the phone's open connection and forwards the message. 4. The operating system shows the notification, or wakes the app so it can fetch more.

Try it below. Pick what happens to the phone, then step through the trip.

Notice what each scenario shows. With the phone offline, the push service does not throw the message away; it keeps it for a limited time (you can set how long) and delivers it when the phone reconnects. With the app uninstalled, the push service eventually tells the server that the token is no longer valid, and the server should stop sending to it.

What a payload looks like

Here is a small payload in the shape APNs expects, built and measured with Node.js:

const payload = {
  aps: { alert: { title: "Order shipped", body: "Your parcel leaves the depot today." }, sound: "default" },
  orderId: 4821
};
const text = JSON.stringify(payload);
console.log(text);
console.log(Buffer.byteLength(text, "utf8") + " bytes of 4096 allowed");

Running it prints:

{"aps":{"alert":{"title":"Order shipped","body":"Your parcel leaves the depot today."},"sound":"default"},"orderId":4821}
121 bytes of 4096 allowed

The aps part is what the system shows; orderId is extra data of your own that the app can read. The size matters: Apple documents a limit of 4 KB (4,096 bytes) for standard notifications, and Firebase documents 4096 bytes too. A push is a nudge, not a delivery truck. If the payload is too big, APNs refuses it with a 413 error.

Notification messages and data messages

Firebase describes two kinds of message. A notification message has ready-made visible fields such as a title and a body, and the system can display it for you. A data message carries only your own key-value pairs, and your app's code decides what to do with them. Because a push is small, a common pattern is to send a tiny data message such as "new message in chat 7" and let the app download the full text itself.

Why a push can still go missing

Pushes are best-effort: neither the push services nor the phone promise every message arrives instantly. A few common reasons a notification does not show up: the user turned notifications off for that app in the phone's settings, the token is out of date, the phone was offline longer than the message's lifetime, or the phone's battery-saving rules delayed it. A good app never treats a push as the only way to learn something. It also checks its own server when it opens.

What this means for your own app

If you build a mobile app, you will not talk to phones directly. You will do three things: ask the user for permission to show notifications, save the device token on your server, and send small payloads to APNs or FCM. Handle the "token no longer valid" answer by deleting that token. And keep the payload tiny, with the real data waiting on your server.