Your phone has been sitting face-down for two hours. You killed Slack before a video call to claw back some memory, and you haven't touched it since. Then the screen lights up: a Slack message, sharp and immediate, like the app never left.
It didn't leave. Or rather, it doesn't need to be present to receive mail.
The Postman That Never Sleeps
Both iOS and Android run a single, always-on system daemon dedicated to receiving push notifications. On iOS it's the APNs (Apple Push Notification service) client, baked into the OS itself. On Android it's a component inside Google Play Services called Firebase Cloud Messaging, which holds a persistent TCP connection open to Google's servers. Your individual apps don't maintain their own connections, sitting there waiting for messages. That would drain your battery like a sieve. Instead, one privileged process holds the line for all of them.
When you install an app and grant it notification access, the OS generates a unique device token for that app. Think of it less like a phone number and more like a specific locker at a train station: one locker, one station, one owner. The app ships that token off to the developer's server. When the developer wants to reach you, their backend forwards the message payload to Apple or Google's infrastructure, addressed to your token. Apple or Google handles last-mile delivery.
That delivery goes to the OS daemon. Not your app.
What Happens After the Daemon Catches It
The daemon receives the payload, checks a system-maintained registry, and finds which app owns that token. It locates the bundle ID (something like `com.tinyspeck.slack`) and wakes the app through a tightly controlled mechanism.
On iOS, the OS spins up a background execution context, calls the app's notification handler method, and hands it exactly 30 seconds of CPU time. The app never fully relaunches in any user-facing sense. It runs headless, processes the data, and the OS assembles the visible notification from the payload. Then the context goes back to sleep. On Android, FCM broadcasts an intent to the app's registered `FirebaseMessagingService`, spinning up just that service class even if nothing else in the app is running. The developer can do a small amount of work, pull a thumbnail, update a badge count, before it shuts back down.
In practice: you killed Slack at 9 a.m. At 11 a.m. a colleague posts a message. Their client fires a notification request to Slack's servers. Slack's backend calls the APNs API with your device token and a payload: sender name, message snippet, notification ID. APNs delivers it to the always-on daemon on your phone, which finds `com.tinyspeck.slack`, wakes a background context, calls the handler, and puts the banner on your lock screen. Slack never fully launched. Server to visible notification, on a decent connection, takes under a second.
One daemon. Every app. The whole thing runs like a shared building intercom rather than each tenant wiring their own doorbell to the street.
What People Consistently Misread
The common assumption is that force-quitting an app kills its notifications too. On Android, that's actually partially true: force-stopping an app through Settings can block FCM from waking it until the user relaunches manually, because Android treats a force-stop as an explicit user-intent signal. On iOS, a swipe-up in the app switcher does nothing of the sort. The APNs daemon still delivers. iOS still wakes the background context. The notification arrives regardless, and no amount of aggressive app-switching changes that.
And if you think force-quitting improves battery life, you've been lied to by your own instincts. Because one daemon holds all connections instead of fifty apps each maintaining their own socket, this architecture is one of the more battery-efficient things your phone does. The daemon batches and coalesces where it can. The real drain is what apps do once they wake up, not the waking itself.
So why does any of this matter beyond satisfying curiosity? Because Apple and Google made themselves mandatory middlemen for every notification on their platforms. That's not a quirk. It's a structural choice, with real consequences for privacy and platform control, baked so deep into how phones work that most people will never think to question it.
Your app doesn't need to be alive to reach you. The postal service was built into the foundation long before you installed anything.