How a push notification travels
A push notification feels like a message from one person’s phone to another’s. It is not. It goes through at least two servers, both reached over the internet.
On Apple platforms, your provider server builds a POST request and sends it to APNs over HTTP/2 and TLS. APNs checks your credentials, looks up the device token, and tries to send the payload to that device. On Google’s side, Firebase describes a chain of components: a trusted server environment that builds the request, the FCM backend that accepts it and assigns a message ID, and a platform transport layer that routes it to the device. That layer is the Android transport layer on Android devices with Google Play services, APNs for Apple devices, and the web push protocol for web apps. Firebase states the last step plainly: when the device is online, the message is sent to it.
So a push needs three things at once: your server must reach the vendor, the vendor must be running, and the device must have an internet connection the vendor can reach. Take away any one and the notification waits or disappears.
What happens while the device is offline
Both vendors hold some notifications for a device that is out of reach, but with limits.
APNs may store a notification for 30 days or less, depending on the apns-expiration date the sender sets, and tries again the next time the device is online. Apple says APNs stores only one notification per bundle ID. If you send several to the same device, it keeps one, in most cases the latest, though Apple notes even that is not guaranteed when several arrive in a short time.
FCM stores messages for a device that is not connected and delivers all pending ones when it reconnects, unless they time out first. By default that is four weeks. What survives depends on the message type:
- Collapsible messages can be replaced by a newer message with the same collapse key before delivery. FCM keeps at most four collapse keys per device, and notification messages are always collapsible.
- Non-collapsible messages, such as chat messages, are each meant to be delivered. On Android, FCM stores up to 100 of them. If that limit is reached, all stored messages are discarded and the device later receives a special message saying so, so the app can resynchronise.
A notification that is replaced, discarded or past its expiry is not delivered late. It is gone. How long can a message wait to be delivered? compares these limits with other systems.
Other reasons pushes go missing
Even online, push is best effort. Apple says APNs may reorder notifications, that lower-priority notifications might be grouped and delivered in bursts, and that notifications may be throttled and in some cases not delivered, depending on how the person uses the app and the device’s power state. Firebase says FCM may deliberately delay messages to stop an app using too many resources, and that a message ID only means the message was accepted for delivery.
The sender side matters too. If the sending phone is offline, its message never reaches your server, so no push is ever created.
What works without the internet
When two devices are near each other, they do not need a vendor’s server to tell one about the other’s message. The pieces are on the device:
- Local notifications. An app can create a notification itself. Apple’s documentation describes local notifications that the system delivers on the app’s behalf, even if the app is not running or is in the background. If the app has received the message by some local path, it can alert the person without any server.
- A local link. Bluetooth LE can connect nearby phones directly. On iOS, an app that declares a Core Bluetooth background execution mode can be woken from a suspended state to handle Bluetooth events. Apple says a woken app has around 10 seconds to complete a task, and that without these modes Bluetooth tasks stop while the app is suspended.
- An outbox. The sender writes each message to durable storage first and keeps it until the recipient confirms receipt, so a message created offline is not lost while the app waits for any path, local or internet.
Devices that relay for each other can stretch this further, which is what an offline mesh network does.
Using both
Push and local delivery solve different problems, and many apps need both. A useful rule is to treat a push as a hint, not as the message. When a push arrives, the app fetches or syncs the real data. When there is no internet, the app delivers over a local link from its outbox and raises a local notification. Either way the message itself lives in storage the app controls, so a lost or collapsed push costs a delay rather than the content.