If you look at your phone right now, you likely have a flurry of messages on your lock screen, ranging from “urgent” Slack DMs to overdue Linear tasks to Uber Eats convincing you to get a coffee delivered for $25.
Some messages are clearly more exciting than others. But if you’re a developer, SaaS product manager, or growth lead, you might be at least a little intrigued about how those messages ended up there.
It’s, of course, a push notification. Push notifications have become a core channel for apps, software products, and services to reach users with timely, relevant information that drives engagement and retention.
In this chapter, we will go through what push notification systems are, how you can build one, and the pros and cons of building versus leaning on notification systems.
What are push notifications?
Push notification systems are infrastructure services that enable applications to send messages to users' devices even when the app is not actively open.
An iOS push notification preview rendered in Knock's push template editor
At their core, these systems provide a way to reliably deliver time-sensitive information to millions of devices across different platforms, networks, and geographies.
Push notifications vs SMS messages
While both push notifications and SMS messages can deliver alerts to users' devices, they operate through fundamentally different channels and offer distinct advantages.
SMS messages travel through cellular networks using the traditional Short Message Service, requiring a phone number and potentially incurring carrier fees.
Push notifications, on the other hand, leverage internet connectivity and platform-specific services like Apple Push Notification Service (APNs) or Firebase Cloud Messaging (FCM) to deliver messages directly to installed applications.
Push notifications offer several key benefits over SMS:
- they're typically cheaper to send.
- they support rich media content like images and interactive buttons.
- they provide better delivery tracking and analytics.
- they can be easily managed through user preferences within your app.
How push notifications work
Push notifications operate through a coordinated system involving your app, your server, and platform-specific notification services. We wrote an entire article on this, but here's an overview of how the process works.
Requesting permission to send push notifications
Regardless of you device or platform, you'll need to obtain permissions to send a user a notification:
A diagram of how push notifications permissions are requested
When users first install your app, they're prompted to allow notifications. On iOS, this permission request is mandatory through a system dialog, while Android historically allowed notifications by default until Android 13, which now requires explicit opt-in similar to Apple's approach.
Once permission is granted, here's what happens:
- Device requests a token. The device communicates with the platform's notification service: Apple Push Notification Service (APNS) for iOS or Firebase Cloud Messaging (FCM) for Android.
- Service sends per-device, per-app token. This communication generates a unique device token that identifies that specific app installation on that specific device.
- Device sends token to your server. Your app then sends this device token to your application server, which stores it for future use. This token is essential. If a user reinstalls your app or switches devices, they'll receive a new token that must be registered with your server.
Next, there's a separate process to actually send a notification.
Sending push notifications
This process involves both your systems and delivery providers:
A diagram of how push notifications are sent
Once a push notification is triggered, here's what happens:
- Your app server sends a message and token to APS/FCM. Your server prepares the message and sends it to the appropriate notification service (APNS or FCM) along with the recipient's device token.
- APNS/FCM send message to device based on token. The notification service verifies the message and uses the token to identify and route the notification to the correct device.
This architecture allows notifications to reach users even when they're not actively using your app, creating valuable engagement opportunities without requiring your app to maintain constant connections to your server.
Challenges for mobile developers
The downside of this, particularly for mobile developers, is that you need a backend database and a server if you want to send users push notifications. This application layer decides what to send, to whom, and when. This is where you implement business logic, such as segmenting users, personalizing content, and respecting user preferences.
Building a push notification system means orchestrating all these layers while handling edge cases like token expiration, rate limiting, delivery failures, and platform-specific quirks. You'll need to track delivery status, manage device registrations, handle unsubscribes, and monitor performance across your entire notification pipeline.
The complexity multiplies when you consider scale. Sending one notification is straightforward. Sending millions of messages within seconds, while maintaining delivery guarantees, handling failures gracefully, and providing real-time analytics, requires careful architectural decisions that we'll explore in the next chapter.