The apns-expiration
field governs how long Apple will hold on to an apns message before giving up on delivering it (for example, if the device is turned off).
According to their docs, a value of zero means "no retention": meaning that if the message can't be delivered immediately, its discarded.
But what happens if the header isn't specified? In other words, what is the default behavior?
apns-expiration. The date at which the notification is no longer valid. This value is a UNIX epoch expressed in seconds (UTC). If the value is nonzero, APNs stores the notification and tries to deliver it at least once, repeating the attempt as needed until the specified date.
They expire one year after creation and must be renewed in order to let you send in-app notifications to your end-users. One month prior to expiration, the iOS Dev Center and the mag+ Publish portal will email a warning to your associated brand admin.
The APNs request header key for the collapse identifier is apns-collapse-id and is defined in Table 6-2. For example, a news service that sends the same headline twice in a row could employ the same collapse identifier for both push notification requests.
The system makes every attempt to deliver local and remote notifications in a timely manner, but delivery isn't guaranteed. The PushKit framework offers a more timely delivery mechanism for specific types of notifications, such as those VoIP and watchOS complications use.
My information isn't based on documentation but rather on stats gathered from a multi-million users system. The policy at this time is to retain push messages for a long time (exactly how long I dont know - we've seen 1M seconds retention in some cases). Of course, as this isn't documented it could change in the future.
Note that this default value is similar to Google's policy (where the default is 2419200 seconds), with the exception that Google's policy is documented.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With