Push messages sent via Localytics are initially transmitted to Amazon SNS (Simple Notification Service), where they are then routed to APNS (Apple Push Notification Service) or GCM/FCM (Google/Firebase Cloud Messaging) in order to deliver the message to actual devices.
In regards to iOS:
According to This Page in the Apple Developer Library:
Apple Push Notification service includes a Quality of Service (QoS) component that performs a store-and-forward function. If APNs attempts to deliver a notification and the destination device is offline, APNs stores the notification for a limited period of time and delivers it when the device becomes available again. This component stores only the most recent notification per device and per app. If a device is offline, sending a notification request targeting that device causes the previous request to be discarded. If a device remains offline for a long time, all its stored notifications in APNs are discarded.
So, Apple will only store the most recent Push message targeting a device for a limited (though unspecified) period of time.
In regards to Android:
According to the FCM Developers' Guide and the GCM Developer's Guide:
FCM/GCM usually delivers messages immediately after they are sent. However, this might not always be possible. For example, if the platform is Android, the device could be turned off, offline, or otherwise unavailable. FCM/GCM might intentionally delay messages to prevent an app from consuming excessive resources and negatively affecting battery life.
When this happens, FCM/GCM stores the message and delivers it as soon as it's feasible. While this is fine in most cases, there are some apps for which a late message might as well never be delivered. For example, if the message is an incoming call or video chat notification, it is meaningful only for a short period of time before the call is terminated. Or if the message is an invitation to an event, it is useless if received after the event has ended.
You can use the time_to_live parameter, supported in both HTTP and XMPP requests, to specify the maximum lifespan of a message. The value of this parameter must be a duration from 0 to 2,419,200 seconds (28 days), and it corresponds to the maximum period of time for which FCM stores and attempts to deliver the message. Requests that don't contain this field default to the maximum period of four weeks.
Another advantage of specifying the lifespan of a message is that FCM/GCM never throttles messages with a time_to_live (TTL) value of 0 seconds. In other words, FCM/GCM guarantees best effort for messages that must be delivered "now or never." Keep in mind that a time_to_live value of 0 means messages that can't be delivered immediately are discarded. However, because such messages are never stored, this provides the best latency for sending notification messages.