iOS 13 - silent push notifications are no longer reliable
Asked Answered
S

0

40

iOS 13 changes:

Change 1: In iOS 13 Beta 6, a silent remote notification (AKA Background Notification) with priority 10 is no longer handled by the OS and dropped. This was documented in the past but never enforced.

Doc:

It's an error to specify this priority (10) for a notification whose payload contains the content-available key.

Log:

error 14:11:19.224387 +0300 dasd Not Supported: High-priority silent push. (App=)

default 14:11:19.224713 +0300 dasd Daemon Canceling Activities: {( com.apple.pushLaunch.com.some.bundle:64660B )}

default 14:11:19.225032 +0300 dasd CANCELED: com.apple.pushLaunch.com.some.bundle:64660B at priority 10 !

default 14:11:19.225363 +0300 dasd Removing a launch request for application by activity

Change 2: a new key, apns-push-type, is required when delivering notifications to devices running iOS 13 with the value background or alert.

After complying with the above, I'm still seeing random behavior regarding silent remote notifications. I can see that the notification arrives to the device and in some cases (even when the device is connected to a power source) the notification is dropped by the OS.

Fail Log:

default 12:19:33.450155 +0300 dasd Submitted Activity: com.apple.pushLaunch.some.bundle:3B0049 at priority 5 <§private>

default 12:19:33.457216 +0300 dasd Push not allowed for <§private>

default 12:19:33.457355 +0300 dasd Daemon Canceling Activities: {( com.apple.pushLaunch.some.bundle:3B0049 )}

Success log:

default 14:37:33.633462 +0300 dasd Submitted Activity: com.apple.pushLaunch.com.some.bundle:D1EEDF at priority 5 <§private>

default 14:37:33.639191 +0300 dasd Adding a launch request (<§private>) for application by activity <§private>

default 14:37:33.639240 +0300 dasd Launch requests for <§private>: <§private>

Going back to the doc:

Specify 5 to send the notification based on power considerations on the user’s device. Use this priority for notifications whose payload includes the content-available key. Notifications with this priority might be grouped and delivered in bursts to the user’s device. They may also be throttled, and in some cases not delivered.

From what I'm seeing, silent notifications are throttled and not delivered randomly (even if the battery is full and the device is connected to a power source)

Still trying to figure out if this is the correct behavior or a bug that Apple is going to fix.

Secessionist answered 10/9, 2019 at 13:16 Comment(10)
See #57578583Rich
Thanks, matt. The last comment there says: "Good news: Amazon pushed a fix for this last night. Silent notifications are working reliably with SNS and iOS 13." This is not what I'm seeing.Secessionist
Yes I noticed that. This suggests there is a solution though. :)Rich
It works better on iOS13 GM version.Reglet
In testing, it looks like when an app is built with Xcode 11 GM, silent notifications from SNS are received as expected while the app is running in the foreground or background. But if the app was built with a prior Xcode 11 beta, then silent notifications from SNS are only received while the app is running in the foreground.Pannier
Did you get a solution? Can you add sample payload?Microbiology
still, have this problem in iOS 13.2, as soon as open the app (switch to foreground they will be delivered)! @Secessionist any update? ThanksCeil
@MoFarhand Im having the same behaviour on iOS 13.2.3Phrasing
BTW I eventually solved my problem by adding a header attribute: --message-attributes '{"AWS.SNS.MOBILE.APNS.PUSH_TYPE":{"DataType":"String","StringValue":"background"}}'Phrasing
any updates @Segev?Pantia

© 2022 - 2024 — McMap. All rights reserved.