#19 - How Push Notifications Actually Work

We pushed back the launch date for our MVP by a week (thank god), so that means I have the time to keep my 18-week streak of blog posts going.

Given that all I’ve thought about for the past several weeks is the phone app we’re building, this week’s article is related to — you guessed it — phone apps. Specifically:

How do apps trigger push notifications? And how does a phone receive and manage them?

Let’s use the app I’m building as an example.

Our app is intended to help friend groups stay up to date with each other’s lives. When a user posts a video to one of their groups, everyone in the group should get a notification about it.

We’ll step through this scenario in chronological order, from the moment a user installs the app to the instant they tap on a notification and open up that newly posted video.

Step 1: Getting a Device Token

Requesting Notification Permission

When someone first installs our app and opens it for the first time, we need to request notification permission. On iOS, a native system dialog will ask if the user wants to allow our app to send notifications. On Android, permission is typically granted automatically on install for most OS versions, although newer Android versions also incorporate runtime permission flows.

Retrieving the Device Token

Once the user grants permission, the operating system (iOS or Android) generates a unique device token (or “registration token” in Firebase Cloud Messaging). Think of this token as the “phone number” your app can dial when it wants to alert the user.

• iOS: Your app calls APIs like registerForRemoteNotifications(), the OS contacts Apple Push Notification service (APNs), and APNs returns a token.

• Android: Your app registers with Firebase Cloud Messaging (FCM), and FCM returns a registration token.

At this point, the OS passes that token back to our app.

Step 2: Storing the Token on Our Backend

Sending the Token to the Server

Our app won’t do much good with this token if it just sits around on the device. We need to associate it with the user’s account in our backend. So we’d make an API call something like POST /api/register-device-token, including the newly retrieved token.

Why Store the Token?

Once our server knows each user’s device token, it can target notifications specifically to them. Without this mapping from “user” to “device token,” the server has no way to say “Send a push to Alice’s phone.”

Token Updates & Invalid Tokens

Over time, device tokens can change (e.g., user reinstalling the app, OS updates). That means our app should handle token refresh events, promptly sending the new token to our server to keep everything in sync. If we accidentally store an old token, notifications will fail to deliver.

Step 3: A User Posts a Video

Triggering an Event

Now let’s imagine one of our users, Alice, posts a fresh new video in a group called Band Class Besties. Our backend sees that a new video has arrived and knows that Bob, Carol, and Dave are in the same group.

Making the Decision to Push

The moment Alice’s video post is processed, our server does the logic: “Everyone in Band Class Besties should get a ‘New video posted by Alice’ notification.” The server knows who’s in the group and can look up the device tokens for each member.

Step 4: Sending the Notification Request to APNs/FCM

Crafting the Notification Payload

Our backend constructs a message payload. Something like:

{
  "title": "New Post in Band Class Besties",
  "body": "Alice just posted a video!",
  "data": {
    "videoId": "abc123",
    "groupId": "band-class-besties"
  }
}

That payload also includes each user’s device token.

Authenticating with the Push Service

To connect to either Apple Push Notification service (APNs) or Firebase Cloud Messaging (FCM), our server uses the appropriate credentials:

• iOS/APNs: Typically an APNs authentication token key or certificate.

• Android/FCM: A server key configured in our Firebase project.

Our server sends an HTTPS (or HTTP/2) request to APNs or FCM, including the notification payload plus the device tokens for Bob, Carol, and Dave.

Step 5: The Push Service Delivers the Notification

APNs and FCM Handling

• APNs: Apple checks that our credentials are valid and that the token is still correct. Then it routes the notification to each user’s iOS device.

• FCM: Firebase receives the request, validates our credentials, and finds the corresponding Android device(s).

Queuing for Offline Devices

If one of our users’ phones is offline, the push service will queue that notification and deliver it when the device reconnects (subject to time-to-live constraints).

Step 6: The Phone Receives & (Potentially) Preloads Content

OS-Level Notification Handling

When Bob’s phone is connected, iOS or Android sees the incoming push from APNs or FCM. The OS decides how to show the alert: maybe a banner at the top of the screen, a badge on our app’s icon, or both.

Background Fetch and Caching the Video

Here’s the fun part for our video-centric app. If we set the notification payload to be delivered silently (or if the OS allows background processing at this moment), our app can wake up in the background briefly. We can then:

1. Fetch the newly posted video metadata from our server.

2. Optionally start caching the video so that if Bob taps on the notification, the video is already there, ready to play.

Note: Silent/background notifications have additional constraints. iOS, for instance, may throttle how often they’re delivered, especially if the user force-quits the app frequently. Android also has limits to preserve battery. But when it works, this can dramatically improve the user’s experience — there’s nothing quite like opening a notification and seeing zero loading time.

Step 7: The User Taps the Notification

Foregrounding the App

Tapping the notification launches (or foregrounds) our app.

Deep Linking to the Video

Because our notification payload includes the video ID, our app can instantly direct Bob to the Band Class Besties screen, display the new post, and autoplay the cached video if we’ve already fetched it. If we didn’t do background caching, the app might fetch it now.

And voila! Everyone’s been notified that Alice posted a new video.

It may sound silly, but the humble push notification is one of the greatest value adds of our app. If that you’re thinking, “you’re right Rayhan, that does sound silly.” then stay tuned for more details on the app. Coming soon…

Quick reminder - If you appreciate my writing, please reply to this email or “add to address book”. These positive signals help my emails land in your inbox.

If you don't want these emails, you can unsubscribe below. If you were sent this email and want more, you can subscribe here.

See you next week — Rayhan