How Do Push Notifications Reach My Phone? Push Tokens and the Delivery Flow

Without even opening the app, a notification like “your order has shipped” pops up on your screen. Out of countless devices, how does it reach exactly your phone — and even when the app is closed? Meanwhile, with notifications turned off, the same app stays silent.

In this post, I’ll unpack, without any code, how a push notification reaches your phone, following its delivery flow.

The app doesn’t send to your phone directly #

Let me clear up a common misconception first. A notification isn’t fired straight from the service to your phone. The service doesn’t even know whether your phone is on right now, whether it’s connected to the internet, or where it is — and it has no direct address for your phone.

So a notification crosses a bridge in the middle. For iPhones it’s the push server Apple runs, and for Android the one Google runs. The phone normally keeps a persistent background connection with this push server, and notifications are always delivered to the phone through it.

A push token is your phone’s address #

So how does it single out your phone among so many? This is where the push token comes in. When you install an app and allow notifications, the phone is issued a unique token that points to “this app on this phone.” It’s a kind of delivery address.

The app sends this token to the service’s server and stores it. Later, when sending a notification, the service asks the push server to “deliver this message to this token,” and the push server finds the phone matching that token and pushes the notification down. Because the token serves as a precise address, the notification doesn’t go to the wrong person.

The full flow of a notification arriving #

Now let me connect the whole flow. When a service decides to send a notification, it specifies the stored token and sends a request to Apple’s or Google’s push server. The API mentioned earlier is exactly the channel used for this request. The push server finds the phone matching that token and delivers the notification, and the phone displays the received content.

This whole process usually finishes within a few seconds. The reason a notification arrives even when the app is closed is that it’s the connection between the phone and the push server, not the app, that receives it.

Permissions and tokens can change #

There are several reasons a notification might not arrive. The user declined notification permission from the start, or turned it off later. Without permission, the token is never issued — or, if it was issued before permission was revoked, delivery is blocked.

Tokens aren’t forever either. If you delete and reinstall the app, or the system reissues the token, the old token becomes invalid. If the service keeps sending to a now-invalid old token, the notification can’t arrive. So a well-built service keeps refreshing tokens and clears out ones that can no longer be used.

So, when you use push #

When planning push notifications, there are a few things to weigh together. First, when and why to request permission. Asking for permission the moment the app first opens tends to get declined. It’s better to ask after the user understands why notifications are helpful.

The volume of notifications matters too. Send promotional notifications too often and users turn notifications off or delete the app. Permission, once turned off, is hard to win back. So for truly important notifications, it’s safer not to rely on push alone but to keep another channel like email alongside it.

Why this makes work easier for non-developers #

• You know why they don’t arrive. When notifications fail for only some users, you can recognize it as a likely permission or token issue and know where to start investigating.
• You design the permission request. Knowing that permission, once declined, is hard to reverse, you can decide carefully when and how to ask.
• You set a notification policy. Knowing that excessive notifications invite blocking and deletion, you can decide what to send and what to hold back, protecting user trust.

Wrapping up #

Today we looked at how a push notification doesn’t come straight from the app but through Apple’s and Google’s push servers, how a push token serves as the address pointing to your phone, and how arrival depends on the state of permissions and tokens. The key is that, because a service can’t reach the phone directly, it goes through an intermediary.

If you’re curious how notifications tie into apps, read App vs. Web — Native, Hybrid, and App Store Review; if you’re curious about the API that serves as the channel for a service to request the push server, read What Is an API.