Lesson 4 of 11 ·11 min read ·Reviewed 6 August 2026

1. The problem push solves

Your backend cannot simply send a message to a phone. The phone has no public IP, sits behind NAT, and moves between networks all day. And if every app held its own network connection open waiting for messages, the battery would be dead by lunch.

The solution: the OS maintains one single persistent connection per device to its platform's push service, Google's FCM (Firebase Cloud Messaging) or Apple's APNs (Apple Push Notification service), and every app on the phone shares it. Your message rides that shared pipe. This is why push is OS infrastructure, not something an app can build itself, and why the platform services are unavoidable middlemen.

2. The full path at a glance

Your backend            FCM / APNs                 Device OS              Your app
     |                       |                          |                     |
     |                       |     (one persistent      |                     |
     |                       |<===  connection, all  ===|                     |
     |                       |      apps share it)      |                     |
     |                       |                          |                     |
     |                       |<-- 1 app requests token--|<-- on startup ------|
     |                       |--- device token -------->|-------------------->|
     |<-------- 2 POST /devices { token } ------------------------------------|
     |  store token against user                        |                     |
     |                       |                          |                     |
     |  (order ships)        |                          |                     |
     |-- 3 send message ---->|                          |                     |
     |  POST /messages:send { token, payload }          |                     |
     |<-- per-token results -|                          |                     |
     |  (a dead token here? prune it: step 6)           |                     |
     |                       |-- 4 push down the pipe ->|                     |
     |                       |   (held + retried if     |                     |
     |                       |    device offline)       |                     |
     |                       |                          |-- 5 route by app -->|
     |                       |                          |   display (notif.   |
     |                       |                          |   message) or wake  |
     |                       |                          |   the app (data)    |
     |<-------- app fetches details over your API (notify-then-fetch) --------|

3. The flow, step by step

POST /devices
Authorization: Bearer <your API's access token>

{ "token": "fMEQ4...", "platform": "android" }

POST https://fcm.googleapis.com/v1/projects/myapp/messages:send
Authorization: Bearer <service-account access token>
Content-Type: application/json

{
  "message": {
    "token": "fMEQ4...",
    "notification": { "title": "Order shipped", "body": "Arriving Thursday" },
    "data": { "order_id": "1234" },
    "android": { "ttl": "3600s", "collapse_key": "order_1234" }
  }
}

The grid is the shared model; the platforms differ at the edges. Android hands data messages to your code subject to message priority and Doze, and a force-stopped app (swiped away is fine; a force stop from Settings is not) receives nothing until the user relaunches it. iOS treats a data-only message as a background push: the app must declare the remote-notification background capability, and the system decides if and when to run it, throttling freely. That discretion is why the best-effort callout above applies doubly to data messages.

4. Security: what goes in the payload

Two credentials to keep straight:

• A device token is not exactly a secret (it is useless without your server credentials), but it is user-linked data; do not leak or log it casually.
• Your service-account key / .p8 key is fully a secret: anyone holding it can push arbitrary notifications to your entire user base, which is a phishing machine. Same handling as any production API key.

5. Variations worth knowing

• Silent push: a data-only message with no visible notification, used to trigger background sync ("new email exists, go fetch"). Both platforms throttle these hard (iOS especially), so they are a hint, not a scheduler.
• Rich push: images, action buttons ("Reply", "Mark done"), and progress-style updates. On iOS this runs through a notification service extension, a tiny bit of your code that can rewrite the notification (e.g. download the image, or decrypt a payload) before display. End-to-end-encrypted messengers use exactly this hook: the push payload is ciphertext, decrypted on-device by the extension.
• Topics and groups: instead of sending to tokens one by one, FCM lets devices subscribe to a topic (breaking-news) and you publish once. Good for broadcast; useless for per-user messages.
• Web push: the same architecture exists for browsers: a service worker receives the message, the push services are run by the browser vendors, and your server authenticates with VAPID keys instead of a service account. Same token-registration, same hygiene problem, same best-effort delivery. This is what a PWA uses, and it closes the loop with the first lesson in the course: push is the capability that most often forces the native-vs-web decision.

6. Common gotchas

Reviewed 6 August 2026.