根据Apple's APNs docs，从iOS 13 开始，http api 的客户端必须发送apns-push-type 和apns-priority 的标头字段，否则请求将失败。果然，我们更新到 iOS 13 测试版的用户不会收到我们通过 AWS/SNS 发送的静默推送通知。
AFAICT，无法将这些标头字段“注入”到 SNS 实际发送的请求中。但亚马逊似乎理所当然地应该这样做，因为没有它，数十亿的通知很快就会开始失败。
有人知道他们是否有计划很快这样做吗？或者也许他们已经在做，而我错过了什么？
【问题讨论】：
在我的测试中，SNS 似乎确实添加了 实际上，Apple / iOS 似乎尚未强制执行 apns-push-type 字段。apns-push-type 字段要求.通过Knuff 发送的推送不包含此标头，但它们会被 iOS 13 beta 8 设备接收。我还可以在 iOS 13 设备上接收通过 SNS 发送的显着通知（即用户可见通知）。突出的通知对您有用吗？
既然您说您只注意到静默通知的问题，那么您可能会遇到与 apns-priority 值的冲突：
apns-priority 通知的优先级。如果省略此标头，APNs 会将通知优先级设置为 10。
指定 10 以立即发送通知。值为 10 是 适用于触发警报、播放声音或 标记应用程序的图标。 指定此优先级是错误的 有效载荷包含内容可用密钥的通知。
指定 5 根据电源考虑发送通知 用户的设备。将此优先级用于其有效负载的通知 包括 content-available 键。 具有此优先级的通知 可能会被分组并以突发方式传送到用户的设备。他们 也可能会受到限制，并且在某些情况下无法交付。
尝试使用apns-priority = 10 和content-available 键（用于静默推送）发送通知是错误的。也许这就是你的无声推送被放弃的原因？
【讨论】：
content-available) 通知？
content-available 标志，但它也不适用于我通过 SNS。如果我将优先级设置为5，当我使用 Knuff 时，相同的有效负载可以正常发送。我想知道 SNS 是否使用apns-priority = 10 发送所有通知。这肯定会导致通知被丢弃。
亚马逊回复了我们的支持请求：
感谢您联系 AWS Support。我是***，今天我将协助您处理此案。
我了解 Apple 将在 iOS 13 中实施新协议。根据新协议，所有 HTTP 通知的标头中都必须包含“apns-push-type”和“apns-priority”字段。
我们知道这个问题，工程团队正在努力解决这个问题。不幸的是，没有解决方法，支持团队对工程团队的路线图和功能的 ETA 没有任何可见性，因此我无法提供支持 iOS 13 标头的日期。我强烈建议您密切关注 AWS 发行说明，以获取有关此问题的更新[1]。
对于给您带来的不便，我深表歉意，希望工程团队尽快解决问题。
【讨论】：
apns-priority 设置为 10，正如他们所说，“为有效载荷包含内容可用密钥的通知指定此优先级是错误的。”所以警报通知会很好，但静默通知将有一个无效的apns-priority。
apns-push-type 标头要求。随着 iOS 13 发布日期的临近，看看这会如何发展会很有趣......
好消息！ AWS 宣布 SNS 现在支持将额外的移动推送通知标头作为消息属性。
此更改适用于 iOS 13，包括 apns-push-type、apns-priority 和 apns-topic 标头。
【讨论】：