iOS 设备重启后未发送静默推送通知

Question

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

Answer 1

In short:

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.

More details:

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:

• a 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},]}}

• a 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.