Many thanks for your reply. I think the fundamental issue is what is a late notification when it comes to VoIP.. The answer comes from common sense. Clearly the current scenario where an offgrid device gets an APNS voip push for a call 3 minutes in the past is not correct... We will make the relevant change in our app on our end but to be honest its a change that clearly should have been done on server.... The CPU time incurred to check an expiration time before sending and throw away if expired in miniscule... Many thanks for the followup nonetheless

Many thanks for the feedback. And noted on new feature. My questions however is what is point of apns-expiration if Apple does not adhere to it... It puts extra pressure on far end device to accept or reject a notification on basis the passed boolean (which may also be wrong).... It would be nice if apple can make a server side adjustment to ensure that it does gated delivery on expiration will solve major headache.... I note apps like WhatsApp have had to let the phone ring and cancel (because you did have the feature).. As developers the less change to the container app, the less impact on customers..

I can confirm we are also encountering same issue... We have tried setting apns-expiration to zero and also an epoch 5 seconds in future in UTC... The exact test is put an iPhone off grid (no WIFI / no 5g). Trigger a apns voip pushkit with expiration set as above. Wait 5 minutes... Reconnect WIFI.. Incoming call arrives....Begging Apple to fix this. VoIP APNS by defintiion is realtime. No point delivering late ones (in contrast to SMS apns).. I have also opened a bug for this . Case-ID: 20013249