Behaviour if user-visible and content-available keys are in APN payload

[Evan Kirkwood]

Hi all,

I noticed Jon Chambers from this list has weighed in on some posts on the Apple Developer forum, so I thought he (or the group here) might have some insight on a problem I'm encountering. Do you happen know what the expected behaviour would be if the notification has alert, sound and/or badge keys and content-available: 1 specified in the payload? Would those be treated as low priority and possibly throttled, or high priority because of the user-visible content? I'm looking at "Configuring a Background Update Notification" in this Apple documentation: https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/CreatingtheNotificationPayload.html#//apple_ref/doc/uid/TP40008194-CH10-SW8  

It states: 

    APNs treats background update notifications as low priority and may throttle their delivery altogether if the total number becomes excessive. But then goes on to say:

    If there are user-visible updates that go along with the background update, you can set the alert, sound, or badge keys in the aps dictionary, as appropriate. There's no definitive statement I can see that describes if the presence of the user-visible content keys has any impact on the otherwise less reliable silent push delivery. If you have any experience in this regard, I would love to hear any thoughts! Thanks!!

[j...@turo.com]

I think the most helpful thing I can offer now is that "throttling"—at least from a delivery perspective—shouldn't be an issue. To the best of my knowledge, APNs as a protocol doesn't look at payloads at all. I'm pretty sure that, from a protocol perspective, there's nothing really enforcing that you're even sending a legit JSON payload at all (though I could be mistaken).

"Delivery priority" is metadata that lives outside of the payload, and the APNs protocol DOES look at that (again, to the best of my knowledge).

I'm not really sure what to make of that line about throttling that you quoted; my guess is that they're referring to the latter, but it may be that they're inspecting notification content. Please note, though, that you're linking to an archived version of the docs that may now be out of date; the current docs live at https://developer.apple.com/documentation/usernotifications.

All that said, there's no way to know what's happening on the APNs servers themselves, and the best I can offer is an informed guess based on past experience and some reading between the lines. APNs only has error codes for "payload too large" and "payload empty," for example, and so it seems unlikely that any deep inspection of content is happening (otherwise, I'd expect something like "payload is malformed" in the list of error codes).

In the end, I guess the real answer is "I don't know," but I hope the perspective is helpful all the same.

-Jon

[Evan Kirkwood]

Thanks for response Jon, definitely appreciate your perspective. That's an interesting observation about the APNs error codes. I wonder if the issue then is not with delivery to the device per se, but rather how the notification is handled once received by apsd service on the device. Perhaps that's where factors like power state of the device, number of background notifications, etc. can impact how the notification is handled.

We've raised a Technical Support Incident with Apple Developer Technical Support on this, and I'll be sure to post back here any further findings we may have.