Method didReceiveRemoteNotification not called after device reboot

Question

Created Sep ’23

Replies 2

Boosts 0

Participants 2

I'm using FCM and differents version of iOS (the oldest is 15.2) on a SwiftUI app. I'm working with silent notifications and everything works well with notifications. I can manage notification behaviour in foreground, in background and when app is killed.

If i launch an fcm like this

"to": "/topics/all",
"priority": "high",
"content_available": true,
"data": {
    "custom_id": 1
}

didReceiveRemoteNotification is called and all works well.

If i use notification attribute like this

"to": "/topics/all",
"priority": "high",
"content_available": true,
"notification": {
    "body": "Sample body",
    "title": "Sample title"
}
"data": {
    "custom_id": 1
}

i see the clickable banner and didReceiveRemoteNotification is also called. I can unistall and reinstll the application, everything still to works.

Problem comes when i reboot/restart the device. After reboot, didReceiveRemoteNotification seems not to be called. if i use

"notification": {
"body": "Sample body",
"title": "Sample title"
}

i see the clickable banner but didReceiveRemoteNotification is not called even after banner click.

After reboot, I tried to send fcm keeping close the app, opening for first time by icon and opening for first time by notification banner but nothing change. didReceiveRemoteNotification remains not called.

The only way to see didReceiveRemoteNotification already called is unistall and reinstall application. Sometimes it's starts to work again after many hours. It's looks like a strage behaviour. I saw a lot of documentation and topics about similar problems and i tried a lot of things, but nothing seems to solve this problem.

Boost

Answer 1

DTS Engineer OP

Apple

Sep ’23

Putting aside that in the problem case, you did not mention that you have used "content_available": true (which is required for didReceiveRemoteNotificationto be called at all), and you MUST unlock the device first after a reboot for this to work at all, if your test cases satisfy both these conditions, then the issue will boil down to the fact that content-available notifications are never guaranteed to be delivered to the app every single time.

Delivery to the app is based on various factors based on the device state and the system decides whether it is appropriate for the app to be woken up at that time or not. Although you may expect up to several background push notifications per hour across all apps on a device, it is entirely possible and appropriate that you may receive none at all.

The system console will log the reason a notification was not delivered to your app. If you filter the console log on your app' bundle ID and check the output during the time you are sending your notification, you will see log lines like:

{name: FileProtectionPolicy, policyWeight: 0.010, response: {Decision: Absolutely Must Not Proceed, Score: 0.00, Rationale: [{classALocked == 0 AND activityFileProtection == ClassB AND timeUntilDeadline == 41435.84119665623}]}} ], FinalDecision: Absolutely Must Not Proceed}

-- OR --

{name: ApplicationPolicy, policyWeight: 50.000, response: {Decision: Absolutely Must Not Proceed, Score: 0.00, Rationale: [{[pushDisallowed]: Required:0.00, Observed:1.00},]}} ], FinalDecision: Absolutely Must Not Proceed}

and so on. Which will mean that the system must have decided to not pass along the notification to your app due to throttling, and not some other issue with your app (in any case, the console log might give you some insight on what might be going on with your app).

0

Answer 2

Next2Qualcuno OP

Sep ’23

Hi, thanks for your replay. After huge investigation my conclusion is related to your end sentence, so i strongly think that system (sometimes) doesn't pass notification at the app while it is in background and even while it is in foreground.

0