In the digital age, where attention is the most valuable currency, the ability to communicate directly and instantly with users is paramount. Push notifications are the primary mechanism for this communication, serving as the modern-day equivalent of a global postal service. They are the short, direct messages that appear on a device’s lock screen or in its notification center, capable of reaching users even when they are not actively using an application.1 This system is a marvel of engineering, designed for immense scale, efficiency, and reliability. To truly understand its power and nuances, it is helpful to establish an analogy that will guide us through its intricate workings.
Imagine the entire push notification ecosystem as a highly sophisticated postal service. In this system, there are four key actors:
The Sender (The Company): This is the application’s backend server. It is the entity that decides a message needs to be sent—be it a flash sale alert, a new message notification, or a reminder about an abandoned shopping cart.1 In our analogy, this is the person who writes a letter, puts it in an envelope, and addresses it.
The Central Post Office (The Platform Notification Service): This is the critical intermediary, the massive, efficient sorting and delivery hub. For Apple devices, this service is the Apple Push Notification service (APNs). For Android, it is Google’s Firebase Cloud Messaging (FCM).1 These services are the backbone of the entire system, responsible for routing billions of messages to the correct recipients every day.
The Recipient’s Mailbox (The User’s Device): This is the customer’s smartphone or tablet. The device’s operating system (iOS or Android) acts as the building’s doorman, receiving all incoming mail and ensuring it gets delivered to the correct apartment—the specific application.
The Mailbox Key (The Device Token): This is perhaps the most crucial piece of the puzzle. It is a unique, anonymous address assigned to a specific application on a specific device. Without this exact address, the Central Post Office has no way to deliver the letter.4
This “push” system stands in stark contrast to older “pull” technologies, where an application would have to constantly ask the server, “Is there anything new for me?” This constant polling is inefficient, draining battery and consuming unnecessary data. The push model is event-driven; the server initiates the communication only when there is something new to say, making it vastly more efficient.2 This report will dissect this digital postal service, from how a user first gets their mailbox key to what happens when the postman arrives at an empty house, providing a definitive guide for developers, architects, and product managers alike.
Before any company can send a notification, the user’s device must have a registered address, and the company must know what that address is. This initial handshake, known as client-side registration, is a multi-step process that establishes the secure channel for all future communication. It also reveals a fundamental philosophical difference in how Apple and Google approach user privacy and developer access.
The journey begins with a request for permission, and the manner of this request is the most significant differentiator between the iOS and Android notification experience.
iOS (The Polite Request): Apple’s ecosystem prioritizes explicit user consent. An iOS app cannot send push notifications without first presenting a system-level prompt asking the user for permission.3 This “ask” is a one-time opportunity. If the user selects “Don’t Allow,” the app is forbidden from asking again. The only way for the user to enable notifications thereafter is to navigate deep into the device’s Settings menu and manually toggle the permission for that specific app.3 This design places a heavy burden on the app developer to choose the perfect moment to request permission—a moment when the user clearly understands the value they will receive in return, such as order updates or critical alerts.1 A premature or poorly explained request often results in a permanent denial.
Android (The Assumed Welcome): Android takes a more lenient approach. When a user installs an app from the Google Play Store, the permission to send push notifications is granted by default.2 The user is automatically opted-in. While this gives developers and marketers immediate access to their user base, it comes with the responsibility of not abusing this privilege. If a user finds the notifications annoying or excessive, they can manually disable them in the app’s settings. Unlike iOS, if a user disables notifications, the app can prompt them again at a later time to re-enable them.3
Once permission is secured (either explicitly on iOS or implicitly on Android), the technical registration process begins.
The client application makes a call to the operating system’s notification framework.
The OS then communicates directly with its native Platform Notification Service (PNS)—APNs for Apple, FCM for Android.4
The PNS generates a unique, opaque, and lengthy alphanumeric string known as the Device Token (or Registration Token in FCM’s terminology).4
This token is the unique address. It identifies a single app on a single device. If the same app is installed on two different phones, it will have two different device tokens. If two different apps are on the same phone, they will also have two different tokens. This token is the cornerstone of the entire targeting system.
The PNS passes the newly generated device token back to the client application. The app’s final responsibility in this handshake is to transmit this token to its own backend server.4 The company’s server then stores this token in a database, typically associating it with a specific user’s account or profile.10 This creates the master “mailing list.” When the company wants to send a notification to Jane Doe, its server looks up her user profile, finds the associated device token for her iPhone, and uses that token to address the message.11
This registration process highlights a critical architectural requirement often overlooked in simple implementations: the dynamic nature of the device token. The token is not a “forever” address. It can be refreshed or changed under several circumstances, such as when a user uninstalls and reinstalls the app, restores their device from a backup onto a new phone, or manually clears the app’s data.10 FCM tokens can also expire if a device has been inactive for an extended period, typically 270 days.10
This impermanence means that a company’s server cannot simply collect tokens and assume they will always be valid. A robust system must include logic for managing the entire token lifecycle. When the PNS attempts to deliver a message to a token that is no longer valid (for instance, because the app was uninstalled), it will return an error response to the sender’s server.13 The server must be programmed to listen for these specific error codes and use them as a signal to “prune” the stale token from its database. Failure to do so results in a bloated and inefficient mailing list, where the server wastes resources attempting to send messages to non-existent mailboxes. This not only skews engagement metrics but can also lead to the server being rate-limited by the PNS for repeatedly sending to invalid addresses.10 Therefore, a scalable push notification architecture is not a one-way street; it is a continuous feedback loop where the server actively maintains the health of its token database based on responses from the PNS.
Once a device is registered, the responsibility for delivery shifts to the massive, complex infrastructure of the Platform Notification Services. While both APNs and FCM serve the same fundamental purpose—acting as a secure and reliable intermediary—they are built with different philosophies and capabilities that reflect the ecosystems they serve.
APNs is Apple’s proprietary and highly integrated service, acting as the single, mandatory gateway for all push notifications destined for Apple devices, including iPhones, iPads, Macs, and Apple Watches.3 Its design emphasizes security, efficiency, and tight control.
Architecture and Protocol: A provider server (the company’s backend) establishes a persistent, encrypted connection with APNs servers using the modern HTTP/2 protocol over TLS 1.2+.16 HTTP/2 is a significant improvement over its predecessors, allowing for features like multiplexing (sending multiple notifications over a single connection), which enhances performance and reduces overhead.18
Authentication: To prevent unauthorized sending, APNs requires the provider server to prove its identity. There are two methods for establishing this trust:
Token-based Authentication (.p8 key): This is
the modern and recommended approach. The developer generates a single
cryptographic key (.p8 file) from their Apple Developer
account. This key is used to sign JSON Web Tokens (JWTs) that are
included with each notification request. This method is more flexible as
the key does not expire and a single key can be used to send
notifications to multiple apps owned by the same developer
team.7
Certificate-based Authentication (.p12 certificate): This is the legacy method. It requires generating a unique SSL certificate for each individual application. This certificate has a one-year lifespan and must be renewed and re-installed on the provider server annually to maintain the ability to send notifications.5
FCM is Google’s comprehensive messaging solution, the successor to the older Google Cloud Messaging (GCM).3 It is designed from the ground up to be a cross-platform service, providing a single, unified API for developers to send messages to Android, iOS, and web applications.8
Role on Android: On Android devices that have Google Play Services installed, FCM is the native, deeply integrated notification system. It communicates with devices via a proprietary channel known as the Android Transport Layer (ATL), which is part of the core Google services running on the device.24 This gives it a high degree of reliability and control within the Android ecosystem.
Role on iOS (The Wrapper/Proxy): The function of FCM on iOS is a critical concept to grasp. When a developer uses FCM to send a notification to an iPhone, FCM does not deliver the message directly. Instead, FCM acts as a sophisticated and convenient proxy or wrapper around APNs.26 The process is as follows:
The developer uploads their APNs authentication credentials (the
.p8 key) to their Firebase project console.27
The company’s server sends a single API request to the FCM backend, specifying the iOS device token and the message payload.
FCM’s servers receive this request, authenticate it, and then, on the developer’s behalf, construct a proper APNs-compliant request.
FCM then sends this newly constructed request to APNs, which handles the final delivery to the iPhone.13
The primary benefit of this approach is abstraction. A developer with both an Android and an iOS app can build their backend to talk to a single endpoint (FCM) for all notifications, and FCM handles the platform-specific complexities behind the scenes.26
The strategic choice between using native PNSs or a cross-platform service like FCM depends on an application’s specific needs. The following table summarizes the key differences, providing a clear basis for architectural decisions.
| Feature | Apple Push Notification service (APNs) | Firebase Cloud Messaging (FCM) |
|---|---|---|
| Primary Platform | iOS, macOS, iPadOS, watchOS, tvOS 16 | Android, iOS, Web 3 |
| Permission Model | Explicit Opt-In (User must grant permission) 3 | Implicit Opt-In (Enabled by default on install) 2 |
| Offline Queuing Policy | Coalesced: Stores only the last notification per app 18 | Stores up to 100 non-collapsible messages; supports
collapse_key 30 |
| Message Expiration | Set via apns-expiration header 18 |
Set via time_to_live (TTL) parameter (default 28 days)
13 |
| Authentication | Token-based (.p8 key) or Certificate-based (.p12) 5 | Server Keys or OAuth 2.0 Access Tokens 12 |
| Rich Media Handling | Requires mutable-content flag and a Notification
Service Extension 34 |
Handled more directly in the payload for Android 3 |
| Advanced Targeting | Primarily single-device token targeting 5 | Supports single tokens, device groups, and topic-based subscriptions 8 |
With the user’s address (device token) securely stored, the focus shifts to the company’s backend server—the mailroom where messages are composed, addressed, and dispatched to the Central Post Office (APNs or FCM).
The “letter” itself is not plain text but a highly structured JSON object known as the payload. This payload contains all the instructions for what the user should see and what the device should do.5
APNs Payload Structure: For iOS, the payload
must contain a top-level aps dictionary. This is Apple’s
reserved namespace for notification parameters. Inside aps,
keys like alert, badge, and sound
dictate the user-facing elements.5 The alert key can itself
be a dictionary containing a title, subtitle,
and body.36 Any custom data intended for the app to process
programmatically (e.g., an internal product_id) must be
placed outside the aps dictionary at the top level of the
JSON object.
FCM Payload Structure: FCM offers greater flexibility by distinguishing between two payload types. A developer can send one, the other, or both in a single message.8
notification payload: This is a set
of predefined, user-visible keys (title, body,
icon, etc.). When an FCM message contains only a
notification payload and the app is in the background, the
FCM SDK on the device automatically handles displaying the notification
without waking the app’s code.11
data payload: This consists
entirely of custom key-value pairs defined by the developer. A message
with a data payload is always delivered to the
application’s message handling service (e.g.,
onMessageReceived on Android), regardless of whether the
app is in the foreground or background. This gives the developer full
control over how to process the incoming information, allowing for
“silent” pushes that can trigger background data syncs or other
logic.8
It is crucial to note the strict size limits imposed on these payloads. Both APNs and FCM enforce a maximum size of 4 KB (4096 bytes) for standard notifications.16 APNs allows a slightly larger 5 KB limit for Voice over IP (VoIP) notifications.36 This constraint reinforces a core principle: notifications are for delivering concise alerts and triggers, not for transferring large amounts of data.
Once the JSON payload is constructed, the server wraps it in an
HTTP/2 POST request and sends it to the appropriate PNS endpoint (e.g.,
api.sandbox.push.apple.com:443 for APNs development).18
This request is more than just the payload; it includes a set of
critical headers that act as the “stamps” and “addressing information”
on the envelope.
Essential Headers:
:path: This header contains the destination address.
For APNs, its format is /3/device/<device_token>,
where <device_token> is the unique identifier for the
target device.18
authorization: This contains the authentication
credentials. For token-based APNs, it would be
bearer <provider_token>, where the token is the
signed JWT.18
apns-push-type: A required header for modern Apple
operating systems, it must accurately describe the payload’s content
(e.g., alert for user-facing notifications,
background for silent updates). Mismatches can cause errors
or delivery delays.18
apns-priority: This advises APNs on delivery
urgency. A value of 10 requests immediate delivery, while a
value of 5 allows APNs to delay the notification slightly
to optimize for the device’s battery life.18
apns-expiration (APNs) / time_to_live
(FCM): This crucial header tells the PNS how long to store the
notification if the device is offline. A value of 0 means
the PNS should attempt delivery once and then discard it.18
After dispatching the request, the server must diligently process the
response from the PNS. A successful response code, such as an HTTP
200 OK, does not mean the notification has been delivered
to the user’s device. It merely confirms that the PNS has received the
request, validated it, and accepted it for delivery.25
The actual delivery is an asynchronous process that happens later.
The most important information often comes from error responses. If the PNS returns an error indicating the device token is invalid or unregistered (e.g., the user has uninstalled the app), this is the explicit signal for the server to remove that token from its active database, thus maintaining the health of its mailing list.4
A central question that arises is how millions of devices can remain constantly ready to receive a notification at any moment without their batteries draining within hours. The answer lies not in every app maintaining its own connection, but in a highly efficient, centralized architecture managed by the operating system itself.
The notion that every app on a phone is continuously “phoning home” to check for updates is a misconception that would lead to a disastrous user experience. Such a polling-based approach is incredibly inefficient.39 Instead, the mobile OS acts as a single, vigilant gatekeeper.
Upon connecting to a network (Wi-Fi or cellular), the operating system—specifically, core components within iOS or Google Play Services on Android—establishes a single, persistent, and encrypted TCP/IP connection to the servers of its respective PNS.41 This connection is typically maintained over a specific port, such as TCP port 5223 for APNs, with port 443 (standard HTTPS) used as a fallback.41 The key insight is that all push notifications for all apps on the device are funneled through this one OS-managed socket. This consolidation is the foundation of the system’s efficiency, preventing the chaos of hundreds of apps managing their own network connections.39
This centralized, persistent connection is remarkably power-efficient due to a combination of deep software and hardware integration.
Low-Power Listening State: The mobile OS works in concert with the device’s radio hardware (the cellular and Wi-Fi chips). It can place the radio into a low-power “listening” mode, where the TCP connection remains technically open but consumes minimal energy.43 The device is not actively transmitting data; it is passively awaiting an incoming signal.
The Heartbeat Mechanism: A long-lived, idle TCP connection is at risk of being terminated by intermediary network hardware, such as routers or firewalls, which may see the lack of activity as a sign the connection is defunct. To prevent this, the OS and the PNS periodically exchange tiny data packets known as “heartbeats” or “keep-alive” pings.46 These packets are extremely small and serve only to signal “I’m still here,” resetting the inactivity timers on network hardware without fully waking the device’s main processor or demanding significant power from the radio.47
Event-Driven Model: The most significant power saving comes from the “push” model itself. The device is not wasting energy by repeatedly asking a server for updates. It remains in a low-power state until an event—the arrival of a notification payload from the PNS—occurs. Only then does the OS wake the necessary components to process and display the notification.6
This architecture represents a deliberate and fundamental design choice in modern mobile operating systems. In the early days of smartphones, apps had more freedom to run processes in the background. This led to a “tragedy of the commons,” where numerous applications, each trying to maintain its own connection or periodically check for data, would collectively drain the device’s battery. To solve this, platform creators like Apple and Google shifted to a centralized service model. They took on the responsibility of managing the difficult, power-intensive task of maintaining a persistent connection and provided a standardized API for all apps to use. This decision involved a crucial trade-off: it reduced the autonomy of individual developers (who now must use the official PNS as a gatekeeper) in exchange for a vastly superior and more consistent user experience, defined by longer battery life and reliable real-time communication.
A critical test of any delivery system is how it handles a recipient who is not home. In the digital world, this translates to a user whose device is turned off, in airplane mode, or simply without a network connection. The Platform Notification Services have built-in mechanisms for this scenario, but their approaches differ significantly.
When a PNS attempts to deliver a notification and finds the target device is offline, it does not immediately discard the message. Instead, it places the message in a temporary storage queue, waiting for the device to reconnect.21 The rules governing this queue are a point of major divergence between APNs and FCM.
APNs’ “Last-In, First-Out” Policy (Coalescing): Apple’s APNs operates with a policy of coalescing. For a given application on an offline device, APNs will generally store only the single most recent notification. If a second notification for that same app is sent while the device is still offline, the first notification is permanently discarded and replaced by the newer one.18
Analogy: This is like a mailbox designed to hold only one letter. Each time the postman arrives with a new letter, they must remove and discard any letter already in the box to make room for the new one.
Implication for Developers: This behavior has profound implications. Developers cannot rely on APNs to deliver a sequence of distinct notifications to an offline user. If a user misses three separate chat messages, they will only receive the notification for the third one. Therefore, iOS notifications should be designed as stateless “pings” or summaries (e.g., “You have 3 new messages”) rather than as a guaranteed delivery channel for discrete pieces of information.
FCM’s “First-In, First-Out” Queue (with Caveats): FCM provides a more robust and configurable queuing system for Android.
Non-Collapsible Messages: By default, messages
are non-collapsible. FCM will queue up to 100 individual
messages per app for an offline device.14 When the device comes
back online, it will receive this backlog of notifications. If the 101st
message is sent while the device is still offline, the entire queue of
100 messages is discarded. When the app next connects, it will receive a
special onDeletedMessages() callback, signaling that it
missed a large number of messages and should probably perform a full
data sync with its server.13
Time-to-Live (TTL): Developers can attach a
time_to_live parameter to any FCM message, specifying a
duration (up to a maximum of 28 days) for which FCM should store and
retry delivery. If the device does not come online within this window,
the message expires and is discarded. This is essential for
time-sensitive content like a 24-hour flash sale alert.13
Collapsible Messages
(collapse_key): For use cases where only the
latest update is relevant (e.g., live sports scores, weather alerts,
stock prices), developers can assign a collapse_key to
their messages. All queued messages sharing the same
collapse_key will be collapsed, with only the newest one
being stored for delivery—effectively mimicking the behavior of APNs.
FCM can store messages for up to four different collapse keys
simultaneously for a single device.13
When the user’s device is powered on or reconnects to the internet, the operating system’s first orders of business include re-establishing its persistent TCP connection to the PNS. As soon as this connection is live, the PNS detects that the device is back online. It then immediately begins delivering any and all messages that have been stored in its queue for that device’s token, according to the policies described above.13
Once the notification has successfully traversed the internet from the company’s server, through the PNS, and down the persistent connection to the device, the final stage of its journey begins.
The operating system is the first to receive the incoming notification payload. It acts as a receptionist, inspecting the payload to identify the target application (via its unique bundle identifier) and assessing the app’s current state.1 This state is the primary factor in determining what happens next.
App in Foreground: If the user is actively using the app when the notification arrives, the behavior is typically controlled by the app’s code. The OS passes the notification data directly to the running application. The developer can then choose to display a custom in-app banner, silently update the UI with new information, or even ignore the notification entirely if it’s no longer relevant.
App in Background or Terminated: This is the
more common scenario. The app is either not running or is suspended in
the background. In this case, the OS takes full responsibility for
presenting the notification to the user. It parses the
alert, sound, and badge keys from
the payload and renders the corresponding system-level user interface
element.1
The visual representation of the notification is handled by the OS and appears in one or more standard locations: as a banner that drops down from the top of the screen, an item on the lock screen, and an entry in the consolidated Notification Center.1 While the core concept is the same, there are subtle user experience differences between the platforms.
Grouping: Android has long offered flexible notification bundling, where multiple alerts from a single app are automatically grouped into a single, expandable entry. iOS has since adopted similar functionality, grouping notifications by app by default, with options for further customization.3
Persistence: On Android, notifications typically leave an icon in the status bar and remain in the notification shade until the user explicitly dismisses them. On iOS, a notification on the lock screen that is not immediately acted upon is moved to the Notification Center.3
Modern notifications are far more than simple text alerts. Both platforms provide powerful tools to make them more engaging and useful.
Actionable Buttons: Developers can define custom action buttons that appear with a notification, such as “Reply,” “Archive,” or “Add to Cart.” These allow users to perform common tasks directly from the notification without needing to launch the full application.1
Rich Media (Images/Video): Including images or other media can dramatically increase a notification’s impact. The implementation of this feature reveals a fascinating difference in the design philosophies of Apple and Google.
iOS (mutable-content): To attach
rich media on iOS, the server must include the
"mutable-content": 1 flag in the APNs payload’s
aps dictionary.34 This flag is a command to the iOS
operating system. Instead of immediately displaying the notification, it
silently wakes up a small, separate part of the app called a
Notification Service Extension. This extension is
granted a very brief execution window (around 30 seconds) to modify the
notification’s content before it is shown to the user. The common
practice is to include a URL to the image in the custom data section of
the payload. The extension’s code then downloads this image from the URL
and attaches it to the notification content. This process allows for
dynamic content and even end-to-end encrypted payloads, where the
extension decrypts the message just before display.34
Android: On Android, the process is more direct.
The FCM payload can include an imageUrl key directly within
the notification object. The FCM SDK on the device then
handles the task of downloading and attaching the image
automatically.3
This distinction is telling. Apple’s mutable-content
approach empowers the client device. The server sends a
simple instruction, and the device itself performs the heavy lifting of
downloading and processing the media. This aligns with Apple’s
long-standing focus on user privacy and on-device computation.
Conversely, a feature like FCM’s collapse_key empowers the
server and the cloud infrastructure. The server makes a
decision about which message is relevant, and the PNS executes that
logic in the cloud before the data ever reaches the device. This
reflects Google’s core strength in massive-scale, server-side data
processing. Developers building cross-platform applications must
therefore adopt two distinct mental models: for iOS, they ask, “How can
I instruct the device to enrich this notification?”; for Android, they
ask, “How can I instruct the cloud to manage the delivery of this
notification?”
The journey of a push notification, from a company’s server to a user’s screen, is a complex dance of client-side registration, secure server-to-server communication, and efficient, power-saving persistent connections. Understanding this entire lifecycle is essential for building an effective and reliable messaging strategy. The analysis yields several critical takeaways.
Embrace the Platform Differences: A one-size-fits-all approach to push notifications is destined for mediocrity. The fundamental differences in user permission models (explicit opt-in on iOS vs. implicit on Android) and offline queuing behavior (APNs coalescing vs. FCM’s robust queue) must inform the entire design, from the timing of the permission prompt to the very content of the messages themselves.
Token Management is Not Optional: The device token is the linchpin of the entire system, yet it is ephemeral. A scalable and efficient notification backend must treat token management as a first-class concern. This requires building a dynamic system that not only stores tokens but also actively listens for feedback from the PNS to prune invalid tokens, preventing resource waste and ensuring accurate delivery metrics.
The Notification is the Doorbell, Not the House: Given the strict payload size limits and, particularly on iOS, the lack of guaranteed delivery for multiple offline messages, notifications should be treated as a trigger, not a data transport mechanism. The most reliable pattern is to use a push notification to alert the user and “wake up” the application, which then fetches the complete, up-to-date information directly from the company’s server.
Value is the Price of Admission: In an environment saturated with alerts, user attention is a finite and precious resource. The permission to send a push notification is a privilege granted by the user. To retain that privilege, every notification must provide clear, timely, and personal value. Irrelevant or overly frequent messages are the fastest path to being muted or, worse, to the app being uninstalled. A successful strategy is one that respects the user, understands their context, and delivers information that genuinely enhances their experience.
What are push notifications? - Adjust, accessed October 26, 2025, https://www.adjust.com/glossary/push-notification/
Everything You Need to Know About Push Notifications - HUSPI, accessed October 26, 2025, https://huspi.com/blog-open/what-is-a-push-notification-and-how-does-it-work/
Push Notifications on iOS vs Android: the Key Differences - MobiLoud, accessed October 26, 2025, https://www.mobiloud.com/blog/push-notifications-ios-vs-android
How push notifications work on Apple and Android - Knock.app, accessed October 26, 2025, https://knock.app/blog/how-push-notifications-work-on-apple-and-android
Apple Push Notification Service (APNs) - 4Js, accessed October 26, 2025, https://4js.com/online_documentation/fjs-fgl-3.00.05-manual-html/c_fgl_mobile_push_notif_apns.html
Do Push Notifications Really Drain the Battery? - MobiLoud, accessed October 26, 2025, https://www.mobiloud.com/blog/push-notifications-battery
What is Apple Push Notification Service (APNs) in 2025? - Scalefusion Blog, accessed October 26, 2025, https://blog.scalefusion.com/apple-push-notification-service-apns/
Firebase Cloud Messaging - Wikipedia, accessed October 26, 2025, https://en.wikipedia.org/wiki/Firebase_Cloud_Messaging
Push Notification with FCM (High-Level Architecture) & Key Considerations - Medium, accessed October 26, 2025, https://medium.com/@balichowdry/push-notification-with-fcm-high-level-architecture-key-considerations-df60369307c0
Best practices for FCM registration token management | Firebase Cloud Messaging - Google, accessed October 26, 2025, https://firebase.google.com/docs/cloud-messaging/manage-tokens
How Firebase Cloud Messaging (FCM) Works in Android: A Detailed …, accessed October 26, 2025, https://medium.com/@YodgorbekKomilo/how-firebase-cloud-messaging-fcm-works-in-android-a-detailed-system-design-5d937f52b033
Why Most Mobile Push Notification Architecture Fails (And How to Fix It) - Netguru, accessed October 26, 2025, https://www.netguru.com/blog/why-mobile-push-notification-architecture-fails
Life of a message from FCM to the device - The Firebase Blog, accessed October 26, 2025, https://firebase.blog/posts/2019/02/life-of-a-message/
Understanding message delivery | Firebase Cloud Messaging - Google, accessed October 26, 2025, https://firebase.google.com/docs/cloud-messaging/understand-delivery
Push Notifications at Scale: From 100 to 10 Million Users | by Karishma Agrawal | Sep, 2025, accessed October 26, 2025, https://proandroiddev.com/push-notifications-at-scale-from-100-to-10-million-users-975589ec4a29
Apple Push Notification service - Wikipedia, accessed October 26, 2025, https://en.wikipedia.org/wiki/Apple_Push_Notification_service
Apple Push Notification service (APNs): Overview - Hexnode, accessed October 26, 2025, https://www.hexnode.com/blogs/apns/
Sending notification requests to APNs | Apple Developer Documentation, accessed October 26, 2025, https://developer.apple.com/documentation/usernotifications/sending-notification-requests-to-apns
Establishing a connection to Apple Push Notification service (APNs), accessed October 26, 2025, https://developer.apple.com/documentation/usernotifications/establishing-a-connection-to-apns
iOS Push Notification Setup Guide - Userpilot Knowledge Base, accessed October 26, 2025, https://docs.userpilot.com/developer/installation/mobile/ios-push-notification-setup-guide
Setting up a remote notification server | Apple Developer …, accessed October 26, 2025, https://developer.apple.com/documentation/usernotifications/setting-up-a-remote-notification-server
FCM (Firebase Cloud Messaging) - PubNub, accessed October 26, 2025, https://www.pubnub.com/learn/glossary/fcm-firebase-cloud-messaging/
Firebase Cloud Messaging, accessed October 26, 2025, https://firebase.google.com/docs/cloud-messaging
FCM Architectural Overview | Firebase Cloud Messaging - Google, accessed October 26, 2025, https://firebase.google.com/docs/cloud-messaging/fcm-architecture
How Push Notification Delivery Works Internally: APNs and FCM Deep Dive - Clix Blog, accessed October 26, 2025, https://blog.clix.so/how-push-notification-delivery-works-internally/
iOS Push Notification: Backend Choice - APNs vs. FCM? : r/iOSProgramming - Reddit, accessed October 26, 2025, https://www.reddit.com/r/iOSProgramming/comments/1l1orqj/ios_push_notification_backend_choice_apns_vs_fcm/
Get started with Firebase Cloud Messaging - Google, accessed October 26, 2025, https://firebase.google.com/docs/cloud-messaging/get-started
iOS Messaging Setup | React Native Firebase, accessed October 26, 2025, https://rnfirebase.io/messaging/usage/ios-setup
Receive all the push notifications when devices are offline - Stack Overflow, accessed October 26, 2025, https://stackoverflow.com/questions/52522362/receive-all-the-push-notifications-when-devices-are-offline
Comparison - Apple Push Notification Service (APNS), Google Cloud Messaging (GCM), Firebase Cloud Messaging (FCM) and Windows Notification Service (WNS) - Hexnode UEM, accessed October 26, 2025, https://www.hexnode.com/blogs/comparison-apple-push-notification-service-apns-gcm-fcm-wns/
Non-collapsible and collapsible messages | Firebase Cloud Messaging - Google, accessed October 26, 2025, https://firebase.google.com/docs/cloud-messaging/customize-messages/collapsible-message-types
What Happens with Push Notifications When a Device Is Offline? - Alertzy, accessed October 26, 2025, https://alertzy.app/articles/what-happens-with-push-notifications-when-a-device-is-offline
Your server environment and FCM | Firebase Cloud Messaging, accessed October 26, 2025, https://firebase.google.com/docs/cloud-messaging/server-environment
Modifying content in newly delivered notifications | Apple Developer Documentation, accessed October 26, 2025, https://developer.apple.com/documentation/UserNotifications/modifying-content-in-newly-delivered-notifications
Send an image in the notification payload | Firebase Cloud Messaging - Google, accessed October 26, 2025, https://firebase.google.com/docs/cloud-messaging/ios/send-image
Generating a remote notification | Apple Developer Documentation, accessed October 26, 2025, https://developer.apple.com/documentation/usernotifications/generating-a-remote-notification
Custom push payloads - Customer.io Docs, accessed October 26, 2025, https://docs.customer.io/journeys/push-custom-payloads/
Send Messages using Firebase Console, accessed October 26, 2025, https://firebase.google.com/docs/cloud-messaging/send/firebase-console
How does persistent tcp/ip connections preserve battery and lower bandwidth usage?, accessed October 26, 2025, https://stackoverflow.com/questions/19111901/how-does-persistent-tcp-ip-connections-preserve-battery-and-lower-bandwidth-usag
www.mobiloud.com, accessed October 26, 2025, https://www.mobiloud.com/blog/push-notifications-battery#:~:text=They%20operate%20on%20efficient%20connection,picked%20up%20by%20the%20device.
Configure devices to work with APNs - Apple Support, accessed October 26, 2025, https://support.apple.com/guide/deployment/configure-devices-to-work-with-apns-dep2de55389a/web
What technology does the iOS Apple Push Notification Service (APNS) use to maintain a persistent connection with each device to receive such fast push notifications? - Quora, accessed October 26, 2025, https://www.quora.com/What-technology-does-the-iOS-Apple-Push-Notification-Service-APNS-use-to-maintain-a-persistent-connection-with-each-device-to-receive-such-fast-push-notifications
How are Apple devices maintaining persistent connections with Apple servers for things such as APN, FindMy network, etc - Ask Different - Apple StackExchange, accessed October 26, 2025, https://apple.stackexchange.com/questions/436553/how-are-apple-devices-maintaining-persistent-connections-with-apple-servers-for
How to test if iPhone keeps persistent connection to push notification service? - Reddit, accessed October 26, 2025, https://www.reddit.com/r/HomeNetworking/comments/1lc36vz/how_to_test_if_iphone_keeps_persistent_connection/
I stood one of these up last year to play around with it. It works flawlessly bu… - Hacker News, accessed October 26, 2025, https://news.ycombinator.com/item?id=28888630
Heartbeat Mechanism, accessed October 26, 2025, https://docs.oracle.com/cd/E19206-01/816-4178/6madjde6e/index.html
Heartbeat (computing) - Wikipedia, accessed October 26, 2025, https://en.wikipedia.org/wiki/Heartbeat_(computing)
Push technology - Wikipedia, accessed October 26, 2025, https://en.wikipedia.org/wiki/Push_technology
Rretry mechanism of push notification to offline mobile phone - Microsoft Q&A, accessed October 26, 2025, https://learn.microsoft.com/en-us/answers/questions/313795/rretry-mechanism-of-push-notification-to-offline-m
Adding collapse_key in FCM - Stack Overflow, accessed October 26, 2025, https://stackoverflow.com/questions/39886108/adding-collapse-key-in-fcm
Enhancing iOS Push Notifications with Notification Service Extensions: Overcoming Real-World Challenges | by Sirsha Banerjee | Medium, accessed October 26, 2025, https://medium.com/@_.sirsha/enhancing-ios-push-notifications-with-notification-service-extensions-overcoming-real-world-8b71186b54e1