I Did My Own Research on How Mobile Push Notifications Actually Work So You Don’t Have To
After researching numerous blogs and articles on push notifications, I found that many provide only surface-level information. They often describe notifications as data moving from point A to point B without mentioning the underlying technology. Let’s take a closer look at what really happens behind the scenes.
What are push notifications?
Push notifications are messages sent by app publishers that appear as banners or pop-up alerts on users’ devices. These notifications can be received even when the app is not open, and they interrupt whatever the user is doing. Types of push notifications include transactional, marketing, informational, reminders, and geolocation-based notifications.
The benefits of using such alerts include engaging and retaining customers, boosting revenue, increasing conversion rates, and improving communication.
The Evolution of Push Notifications
Push notification technology is relatively new, emerging around 15 years ago. The first push notification was sent on June 8, 2009, during Apple’s Worldwide Developers Conference (WWDC), marking the introduction of the Apple Push Notification Service (APNs). Shortly thereafter, Google launched its own service, Cloud to Device Messaging (C2DM).
Here is a timeline of what happened since:
- 2009–2011:
Apple Push Notification Service (APNs) was launched in 2009 with the release of iOS 3.0.
Google’s Cloud to Device Messaging (C2DM) followed shortly after. Both services laid the groundwork for push notifications but had their limitations. - 2012: Google revamped C2DM into Google Cloud Messaging (GCM), offering more robust features and better reliability for Android devices.
- 2013: Apple introduced new features in iOS 7, enhancing APNs to support more complex and interactive notifications.
- 2015: Google introduced Firebase Cloud Messaging (FCM), which replaced GCM. FCM provided improved functionality, integration with Google’s Firebase platform, and greater control over messaging.
- 2016: Apple continued to refine APNs, adding support for rich media notifications and interactive features in iOS 10.
- 2018: Apple announced a major update with iOS 12, introducing new features for notification management, including grouping and improved handling of notifications.
- 2020 and Beyond: Both APNs and FCM have continued to evolve with improved security features, better UX, more focus on compliance, support for new types of content, and better integration with app ecosystems. iOS supports rich notifications with videos, GIFs, images, and sound bites. Android supports static images like JPG and PNG.
How Push Notifications Actually Work
There are three components that interact in the process of sending the push notifications:
- Operating System Push Notification Service (OSPNS) — APNs, FCM, etc.
- app publisher
- client app
Each mobile operating system, such as iOS, Android, Fire OS, and Windows, has its own push notification service, collectively known as the Operating System Push Notification Service (OSPNS).
The app publisher integrates the app with one or more OSPNSs and uploads the app to the app store.
An OS-specific client app installed on the user’s device receives incoming notifications.
The Process of Sending a Push Notification
User Activation
After downloading and installing the app from an app store, the user opens it for the first time. During the initial setup, the app requests the necessary permissions and registers with the operating system’s push notification service (OSPNS).
Both iOS and Android require apps to obtain user permission before sending push notifications. Users have options to allow notifications once, while using the app, always, or deny them.
Push Notification Service Registration
For iOS apps, the app registers with APNs: the app requests a unique device token from APNs. The device token received from APNs is sent to the app server. This token uniquely identifies the device and allows the app server to send notifications to it.
For Android apps, the app needs to register with FCM: the app requests a unique registration token from FCM. Similarly, the registration token received from FCM is sent to the app server.
These tokens uniquely identify the device and app combination and are used to route notifications correctly.
The APNs device token is a 64-character hexadecimal string like this: d7acb45c3c4d14b02f5a7d8b4c9e1f34a56b7c8d9e0f123456789abcdef1234
The FCMs registration token consists of 130–200 characters and is a Base64-encoded string like this:
fcm_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjY3OTYyOTk2ODMxNDRhYjFjZDNhNzIxOTVjZDFmNDRhIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTIzNDU3NzI2LCJleHBpcmgiOiJ8cHNoYXJlU3VwZXI5c2Fzaz9zYW5kZXIxMjM0NTY3ODkwIn0.W-…
Note: Push notification tokens are usually stored securely in the database to ensure reliable delivery and protect user data. If tokens fall into the wrong hands, they can be misused for unauthorized access, spamming users, or sending malicious notifications, which can compromise security and destroy user trust.
Creating Notifications
The app publisher composes a message, defines the target audience and schedules the message for immediate delivery or for a later time.
The message is sent to the OSPNS, which delivers it to the user’s device as a push notification.
Example of iOS push notification:
{
"aps": {
"alert": {
"title": "Hello",
"body": "This is a push notification"
},
"badge": 1,
"sound": "default"
},
"customKey1": "customValue1"
}Example of Android push notification:
{
"to": "device_token",
"notification": {
"title": "Hello",
"body": "This is a push notification",
"icon": "icon_name"
},
"data": {
"customKey1": "customValue1"
}
}Sending the Notification
Push notifications involve three parties:
- client (device),
- server (app backend),
- OSPNS
When the client opts in, it establishes a persistent connection with the push service (OSPNS) and receives a device token from the notification service.
APNs uses HTTP/2 for communication between the server and the push service, facilitating the delivery of notifications to devices. FCM also uses HTTP/2 for sending notifications from the server to the FCM service, which then routes them to client devices. FCM supports XMPP (Extensible Messaging and Presence Protocol) for certain use cases, such as real-time messaging and bidirectional communication.
The client might inform the server about general preferences or registration details. Such preferences will likely be saved under user settings along with the device token.
When the app publisher creates a notification, the notification needs to be sent to the server. The server then packages this notification with the device token(s) and sends it to the push service. The push notification service is responsible for delivering the notification to the target devices.
The notification is queued on the push service server. The queue is managed by the OSPNS. The service checks if the device is online and if it is, it attempts to deliver the notification to the client.
FCM supports priority settings to ensure that important messages are delivered promptly while optimizing system resources. High-priority messages are sent immediately, whereas low-priority messages are delayed or batched, helping to minimize data usage and conserve resources.
APNs and MSPNS do not have such options but there are custom and third-party push notification services that provide options to set the priority of notifications. Such services are OneSignal, Airship and Braze.
What happens when the device is offline?
Devices maintain a persistent connection with the push notification service. This is how the OSPNS knows when a device is offline or online. Devices and services often use heartbeat or keep-alive messages to confirm that a connection is still active. These periodic messages help ensure that the connection is not lost. If a device does not respond to keep-alive messages or heartbeats, the push service may eventually conclude that the device is offline and continue retrying delivery based on the configured retry logic.
During this time, the notification is kept in the queue. The OSPNS makes periodic attempts to deliver the notification until the device reconnects or the notification expires. The exact frequency and duration of these attempts depend on the push service’s policies and the notification’s expiration settings.
The OSPNS manages the retry mechanism efficiently. Notifications are delivered when the device reconnects to the Internet, however, there is a limit to how long the push service will retain a notification in the queue.
Expiration
For APNs, the expiration time of a push notification cannot be altered. Notifications are retained in the APNs queue for up to 28 days. Similarly, MPNS retains notifications for up to 24 hours
For FCM, push notifications can have an expiration time set by the app publisher. If the device remains offline beyond this expiration period, the notification will be discarded, and it will not be delivered even if the device comes online afterward.
Setting the expiration time can be done by specifying TTL (Time To Live) when sending the notification. If a custom TTL is not set, the service will use its default expiration policy which is 28 days.
If you found this article helpful, consider sharing it with others who might be interested in the technology behind push notifications.
