While testing the delivery of silent notifications (one which has "content-available": 1 in the payload) to my app I noticed that, after device is rebooted notifications are not delivered. Sending the same payload works if the app is running in background or foreground but, after device is rebooted, I do not receive the didReceiveRemoteNotification: callback in AppDelegate .
This happens both on iOS 13 and iOS 12
Your notification was probably delayed by the system and will be delivered after some minutes. You can use the Console.app to filter system logs and try to figure out what's happening under the scenes.
After several attempts I got some insight on the delivery mechanism of the operating system which can help understanding what's happening under the scene.
By using the Console.app on macOS, selecting your attached device and filtering logs of a process named "dasd" which contains your bundle identifier (type process:dasd any:YOUR_BUNDLE_ID ) I figured out that the system actually receives the remote silent notification but cancels the attempt to awake my app.
default 15:37:29.955974+0200 dasd Submitted Activity: com.apple.pushLaunch.YOUR_BUNDLE_ID:7BAB0E at priority 5 <private>
default 15:37:29.958436+0200 dasd Adding a launch request (<private>) for application <private> by activity <private>
default 15:37:29.958611+0200 dasd Launch requests for <private>: (null)
default 15:37:29.972714+0200 dasd com.apple.pushLaunch.YOUR_BUNDLE_ID:7BAB0E:[
{name: ThunderingHerdPolicy, policyWeight: 1.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{timeSinceThunderingHerdTriggerEvent < 300}]}}
], FinalDecision: Must Not Proceed}
default 15:37:33.505325+0200 dasd Submitted Activity: com.apple.pushLaunch.YOUR_BUNDLE_ID:B3D6C8 at priority 5 <private>
default 15:37:33.509388+0200 dasd Adding a launch request (<private>) for application <private> by activity <private>
default 15:37:33.509515+0200 dasd Launch requests for <private>: <private>
default 15:37:33.509778+0200 dasd Daemon Canceling Activities: {(
com.apple.pushLaunch.YOUR_BUNDLE_ID:7BAB0E
)}
default 15:37:33.510334+0200 dasd CANCELED: com.apple.pushLaunch.YOUR_BUNDLE_ID:7BAB0E at priority 5 <private>!
default 15:37:33.510514+0200 dasd Removing a launch request for application <private> by activity <private>
default 15:37:33.510693+0200 dasd Don't have <private> for type 0
default 15:37:33.510865+0200 dasd Don't have <private> for type 1
error 15:37:33.511162+0200 dasd Activity <private> not tracked as being started, ignoring it
More precisely I found out that two policies are enforced by the operating system:
BootTimePolicy which requires at least 120 seconds to elapse after boot before delivering notifications{name: BootTimePolicy, policyWeight: 0.010, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{[Minimum seconds after boot]: Required:120.00, Observed:103.62},]}}
ThunderingHerdPolicy which, in this case, requires at least 300 seconds to elapse after a misterious "ThunderingHerd" event {name: ThunderingHerdPolicy, policyWeight: 1.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{timeSinceThunderingHerdTriggerEvent < 300}]}}], FinalDecision: Must Not Proceed}
After that, following the logs flow I noticed that the system keeps on evaluating this ThunderingHerdPolicy several times and, after 300 seconds, the silent notification was effectively delivered to my app! 🎉✌🏻
So if you are testing the delivery of silent notifications keep in mind that it can be delayed by the system under some circumstances (as Apple says in the docs). This happens to be true after a device reboot.
Please note that this behaviour is not officially documented and that could change in future releases of iOS. You should not rely on this but only use it for debugging purposes.
© 2022 - 2024 — McMap. All rights reserved.