iOS 13 beta 7 Silent Push Bug

I don't use push notifications in my own apps but in my travels through the WWDC videos I remember seeing a few new JSON fields being mentioned. According to https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/sending_notification_requests_to_apns, "apns-push-type" is "Required when delivering notifications to devices running iOS 13 and later, or watchOS 6 and later. Ignored on earlier system versions."

Hope this helps you find the solution!

Have you tried removing the sound and alert completely from the payload?

I have reproduced a very similar problem - posted it here: https://forums.developer.apple.com/message/379262#379262

At this point, I think our reports may essentially be duplicates, but let's see if either get any developer response or tips and tricks for workarounds.

Have you tried @hacknicity 's suggestion of trying some of the new required fields? Will probably give those a go to see if Apple has slipped a change in which will break all users of silent notifications on iOS 13 devices...that would seem like a pretty heavy-handed approach...

Thanks, Hacknicity san, Mungbeans san,

We're using batch.com as a push provider. And at this moment, they don't provide us the ability to handle the parameter value of the "apns-push-type".

They said they are currently preparing the way to update the parameter value by the developers like us. So I'm waiting their update...

I'll update my status again.

Anyway thanks.

Hi Mharlow san,

Thanks for the information.

We're using batch.com as a push provider. And I, of course, have contacted the batch.com's tech support.

And they said they also have confirmed this behavior and they also said that we need to set "apns-push-type" parameter to "background" to make silent pushes working as expected, and this is the exact right way to fix our situation.

But so far batch.com doesn't provide us the ability to set this "apns-push-type" from the developer side, and they are preparing the developer-facing parameter for this "apns-push-type". And it seems it will be available next week.

Once this updates becomes available for me, I'll try that and update the situation again.

BTW, I'm feeling that we are using relatively minor push providers, this might be the kinda hint for this annoying trouble...

Anyway, thanks for the info.

Encounter the same problem.

Slient push cannot trigger didReceiveRemoteNotification in appDelegate even i ensure the new header is fullfilled.

I have ensure the message is received on the device by checking the device console:

<APSCourier: 0x12be782a0>: Received message for enabled topic '' onInterface: NonCellular with payload '{

aps = {

"content-available" = 1;

};

v = 9999;

}' with priority 5 for device token: NO

Also, below logs found :

Received remote notification request 63FD-61D4 [ hasAlertContent: 0, hasSound: 0 hasBadge: 0 hasContentAvailable: 1 hasMutableContent: 0 pushType: Background]

I can see the app is background launch, but it just doesn't trigger the didReceiveRemoteNotification delegate :

-CMSessionMgr- CMSessionMgrHandleApplicationStateChange: CMSession: Client xxxxxx with pid '848' is now Background Running. Background entitlement: NO ActiveLongFormVideoSession: NO WhitelistedLongFormVideoApp NO

Had the same problem where silent push notifications were not working on iOS 13 devices. Adding "apns-push-type" header field solved the issue. Please note this is a APNS POST request header field, not a new key in push JSON.

Let me quickly update my status here.

Last night, our push provider, batch.com, has finally provided us an ability to control the `apns-push-type` value from the developer side like us.

But, there was not enough time for us to update our backend server which is used to create and send silent push payloads to the push provider.

So we've implemented an workaround which was informed us from batch.com .

The workaround is to add `badge: 0` into `aps` object in the payload.

Actually this workaround works as expected, but note that, literally, the app badge is forced to be updated to "0".

Anyway, as everyone kindly said in this thread, I believe the proper way to fix this issue is to set `apns-push-type` to `background` for silent push on the iOS 13.

the didReceiveRemoteNotification could be triggered successfully ?

Our `application:didReceiveRemoteNotification:fetchCompletionHandler` never gets called in iOS 13, only `UNUserNotificationCenterDelegate` methods gets called.

1. Our backend sends the required headers [notiifcations are correctly delivered to our iOS 13 devices].

2. Our payloads hasn't change, so, this method should still be called.

3. I checked and none of our dependencies seems to be doing method swizzling.

4. I tested on iOS 13.1.2 and this is still not working.

Any news about this?

could you explain this - "this is a APNS POST request header field, not a new key in push JSON."?

I had been assuming that this new field should be put in the aps header of the notification

IE what was:

"aps": {

"content-available": 1,

},

should now be:

"aps": {

"content-available": 1,

"apns-push-type" : "background"

},

That statement makes me think it actually belongs somewhere else, but i'm not clear on where.

Anything new regarding the silent push notification?

Do you believe the apns-push-type parameter goes into the "aps" portion of the notification payload?

I have tried this:

{

"aps": {

"content-available": 1,

"apns-push-type": "background"

},

...

}

but the app is still not receiving the silent notifications

Add an empty alert field in the aps header, the silent push came through in my case.

"aps": {

"alert":{},

"content-available": 1

}

Excellent, I intensively use silent notifications, and putting some value in 'alert' solved the problem.