36

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.

Segev
  • 19,035
  • 12
  • 80
  • 152
  • See https://stackoverflow.com/questions/57578083/is-aws-sns-adding-apns-push-type-apns-priority-to-its-ios-push-notification-he?r=SearchResults – matt Sep 10 '19 at 13:26
  • 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. – Segev Sep 10 '19 at 13:29
  • Yes I noticed that. This suggests there is a solution though. :) – matt Sep 10 '19 at 13:32
  • It works better on iOS13 GM version. – Halil İbrahim YILMAZ Sep 11 '19 at 07:00
  • 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. – owjsub Sep 11 '19 at 19:37
  • 1
    Did you get a solution? Can you add sample payload? – karthikeyan Sep 30 '19 at 04:38
  • still, have this problem in iOS 13.2, as soon as open the app (switch to foreground they will be delivered)! @Segev any update? Thanks – Mo Farhand Nov 13 '19 at 02:30
  • 1
    @MoFarhand Im having the same behaviour on iOS 13.2.3 – Boaz Saragossi Dec 04 '19 at 12:06
  • BTW I eventually solved my problem by adding a header attribute: --message-attributes '{"AWS.SNS.MOBILE.APNS.PUSH_TYPE":{"DataType":"String","StringValue":"background"}}' – Boaz Saragossi Dec 25 '19 at 12:31
  • any updates @Segev? – MD. Feb 12 '20 at 14:58

0 Answers0