Silent Push Notification Handler Has Stopped Firing Since iOS13

Judging by this subforum, others are experiencing this same issue lately, namely that application(_:didReceiveRemoteNotification:fetchCompletionHandler:) isn't being called, which seems to indicate that silent notifications are just not coming in anymore.


For us, this seems to have started around the time iOS13 was released, possibly a little earlier, but we've only just noticed recently and started troubleshooting it.


  • We use AWS SNS to dispatch both active and silent notifications
  • The active notifications are all working just fine
  • AWS SNS logs indicate that the silent notifications are correctly sent to APNS (status 200)
  • Yet our app either never receives them or never calls the didReceiveRemoteNotification method in AppDelegate


Solutions we've tried:


  • Ensuring that the notification payload doesn't have any of the user-visible properties (alert dictionary)
  • Setting the new apns-push-type APNS header, along with setting the priority header to 5
  • Omitting the apns-push-type header and priority


Nothing seems to make a difference, and the silent notifications are simply never delivered. We've been testing this across multiple devices with different usage activity patterns for weeks now, and not a single silent notification has ever come through.


Does anyone have any insight on recent APNS changes or Notification API changes that may be causing this issue?


Or alternatively, any idea how to debug this further, given that APNS itself is a black box? As in, the furthest we can see from our backend is the successful delivery of the notification request to APNS, and the only thing we can see from our client's side is that the didReceiveRemoteNotification method is never being called. Are there any other troubleshooting approaches?

Up vote post of Foefirelord Down vote post of Foefirelord
1.5k views
Posted by
Foefirelord
Reply
Add a Comment

Replies

When you're testing are you connected to the debugger? If so, try the "simulate background fetch" operation too.


In one of the networking videos this summer, it was stated that if the user is on low data mode (per network), all "background fetch" will be discontinued. Based on the API naming, I assume this means the same API as silent push i.e. fetchCompletionHandler.

Double check the test devices are not metering their network with Low Data mode enabled.


Out of curiosity, how many silent notifications are you sending per day/per user on average?

Posted by
edorphy
Up vote reply of edorphy Down vote reply of edorphy
Add a Comment

Debugged this with Apple support, and turns out background app notifications are now completely unreliable for background sync purposes, since about 95% of all our users simply don't receive them for a variety of reasons, such as "not enough memory" or other system resource limits.


I guess before iOS13, these limits weren't as strict or as thoroughly enforced, but now, it's at a point where using silent notifications is just pointless, as some users get them consistently, but most either never get them or get them once in a blue moon.


Going to try the new background tasks introduced with iOS13, but given that the old device-initiated background sync basically ran whenever it wanted and without any consistency, I'm not holding my breath.


Seems there's just no way to reliably ensure background sync anymore.

Posted by
Foefirelord
Up vote reply of Foefirelord Down vote reply of Foefirelord
Add a Comment

We were only sending one silent notification every two hours, which is less than the limit described in the docs, which say not to send more than two or three silent notifications per hour.


But we absolutely need to perform a background sync within that two-hour period due to the functionality of our app, and there doesn't appear to be a reliable way of doing that anymore.

Posted by
Foefirelord
Up vote reply of Foefirelord Down vote reply of Foefirelord
Add a Comment