How push notifications actually reach your phone
What actually happens when a notification lands
A phone buzzes. Something appears on the lock screen. It feels instant, like the app somehow reached out and tapped the phone on the shoulder. It didn’t. The app that triggered that notification probably wasn’t even running, and it definitely wasn’t the thing that delivered the message. Almost every push notification on a modern phone travels through infrastructure the app developer doesn’t own: Apple’s Push Notification service on iOS, Firebase Cloud Messaging on Android. The app is just the last stop, not the courier.
That distinction matters more than it looks. It’s the reason a notification can arrive even when the app is force-closed, the reason battery drain didn’t get dramatically worse when every app started sending alerts, and it’s also the reason push channels have become a target worth watching from the adversarial side of the internet.
The persistent connection nobody sees
Polling doesn’t scale. If every installed app opened its own connection every few seconds to ask “anything new for me?”, a phone with sixty apps would be running sixty background radios, and batteries would empty by lunchtime. Mobile operating systems solved this decades ago with a single trick: one long-lived, encrypted connection between the device and the OS vendor’s push gateway, shared by every app on the phone.
On iOS, that connection runs over TLS to Apple’s Push Notification service. The phone opens it once, keeps it alive in the background under OS supervision, and Apple multiplexes every app’s notifications down that one pipe. Android runs the same pattern through Google Play Services and Firebase Cloud Messaging, historically riding on a persistent XMPP-derived channel, now largely HTTP/2 based on the sending side. The device holds one socket open to Google; Google fans messages out to whichever app they belong to once they arrive.
The developer’s server never talks to the phone directly. It talks to Apple or Google’s push gateway, hands over a device token and a payload, and the gateway takes it from there over the connection the OS already maintains. That’s the whole trick: centralize the always-on connection at the OS level, and let every app ride on it instead of maintaining its own.
Two different plumbing systems for two OSes
The two ecosystems diverge on the details in ways that matter to anyone who has to keep dozens or hundreds of devices behaving normally, which is a fairly normal problem for anyone running a device lab or app QA pipeline.
Apple’s system issues a device token per app install, tied to a specific app’s bundle identifier and a specific device. That token has to be sent to Apple with a JWT signed by a private key tied to the developer’s account, and payloads are capped at 4KB. Apple also distinguishes visible alerts, which show something to the user, from silent background pushes, which just wake the app briefly to fetch data with no UI at all, throttled hard by the OS so apps can’t use silent push as a way to run forever in the background.
Google’s model issues a registration token per app instance too, but routes everything through Firebase, and treats messages as either “notification” payloads (rendered by the OS automatically) or “data” payloads (handed to the app to render itself). Android’s aggressive power management, Doze mode and App Standby buckets, will delay ordinary messages for a device that’s been idle, unless the sender marks the message high priority, in which case the OS makes an exception and wakes the radio immediately. That high-priority flag is a real lever, and also a real target for anything trying to guarantee delivery of something the user might not want.
Web push: the same idea, a different door
Browsers do this too, and it’s the version most people actually encounter as a nuisance. A site asks for notification permission, the browser creates a push subscription (an endpoint URL plus encryption keys) through a service worker, and the site’s server can then send messages to that endpoint indefinitely, even with the tab closed, as long as the browser process or a background sync agent is alive. The protocol underneath (Web Push, standardized with VAPID for sender identity) is a smaller cousin of APNs and FCM: one persistent connection between the browser and the push service (again, usually run by Apple, Google, or Mozilla depending on the browser), fanning out messages to whichever site subscribed the device.
This is also the channel behind one of the most common scams on the open web: the “click allow to continue” prompt on a sketchy streaming or download site, which isn’t asking permission to play a video, it’s asking permission to plant a permanent, unmoderated ad channel directly on the lock screen. Once granted, the site can push fake system warnings, fake “you have a message” alerts, or straight ad spam, at whatever interval the sender’s server chooses. There’s no app store review gate on this. It’s just a permission prompt, and browsers have progressively made it harder to grant by accident, adding friction, quiet requests, and one-click bulk revocation in notification settings.
Why push tokens are a fingerprint, not just a mailbox
From the operator’s side of things, a push token is not just a mailing address. It’s evidence. A token is issued by Apple or Google to a specific, real device running a specific app install, and getting one issued at all increasingly requires passing attestation checks: Apple’s DeviceCheck and App Attest, Google’s Play Integrity API. Those systems ask the OS to cryptographically vouch that the request is coming from a genuine, unmodified device and a legitimate build of the app, not an emulator, not a rooted farm, not a repackaged APK.
That’s a real problem for anyone trying to make automated or virtualized devices look organic at scale, because a push token that never gets issued, or one that Apple silently stops delivering to, is a very clean signal that the attestation layer flagged the device underneath it. Fleets of emulators or cloned device profiles used for app-install fraud or engagement farming tend to either fail attestation outright or get tokens that quietly stop receiving messages, which is a much quieter and harder to detect failure than an outright ban. The app looks installed. The notification permission looks granted. The messages just never arrive, and nobody watching client-side logs would necessarily know why.
When push notifications become the abuse channel
Push infrastructure gets targeted from a few different angles, and it’s worth being specific about what those look like rather than treating “notification abuse” as one vague category.
Notification spam and bombing use the channel exactly as designed, just with a sender whose intent is bad: browser push permissions harvested through deceptive prompts, then used for scam or malware-adjacent ad delivery at whatever volume the sending server wants. Fraudulent engagement schemes use push notifications to nudge farmed or automated devices into opening an app and generating fake sessions, clicks, or ad impressions, which only works at all if the fleet behind it can keep getting valid tokens issued, which loops back to the attestation problem above. And on the malware side, security researchers have documented push channels used as a lightweight, always-on signaling path, sometimes called out as a way for compromised devices to receive a short wake-up ping over infrastructure the OS already trusts and never blocks, rather than maintaining their own suspicious-looking connection.
None of these are guaranteed to work, and none of them are undetectable. They’re all fighting an infrastructure layer that was built by Apple and Google specifically to be hard to spoof, hard to impersonate, and easy to revoke.
How platforms fight back
The defenses map fairly directly onto the abuse patterns. Attestation (App Attest, Play Integrity) makes it progressively harder to get a token issued to something that isn’t a real, unmodified device. Rate limiting and reputation scoring on the sender side let Apple and Google throttle or drop traffic from developer accounts or API keys that send at abnormal volume or get flagged for high uncaptured bounce rates. Notification permission itself has gotten more conservative over time on both major platforms, moving from a prompt shown on first launch to something apps are expected to justify contextually, with granular per-app controls and one-tap revocation sitting one settings screen away. Browsers have added friction to the permission prompt itself and made bulk revocation trivial specifically because the deceptive-prompt pattern got common enough to be a known scam vector rather than an edge case.
The net effect is a channel that’s genuinely useful, genuinely central to how modern apps stay responsive, and genuinely hard to abuse at any real scale without leaving a trace somewhere in the attestation, rate-limiting, or permission layers built specifically to catch it.
Curious how the rest of the internet’s plumbing works, and how it gets bent out of shape? The Hidden Internet covers the infrastructure behind bot detection, device fingerprinting, and the systems built to police it.
Get new guides and videos first — join the Telegram channel.