iOS 14及15系统下静默推送通知接收异常问题咨询

在 iOS 14 及后续版本中，当应用被用户手动完全关闭（划掉）时，仅依赖 content-available: 1 的普通静默推送确实无法触发 didReceiveRemoteNotification，这是苹果系统层面收紧后台唤醒权限导致的。下面是几个经过验证的可行方案：

1. 借助通知服务扩展（Notification Service Extension） #

如果你的业务允许推送附带一个“无感知”的通知外壳（比如空标题空内容），可以通过这个扩展来绕开限制：

• 推送 payload 必须包含以下字段：

  {
    "aps": {
      "content-available": 1,
      "mutable-content": 1,
      "alert": {
        "title": "",
        "body": ""
      }
    },
    "custom_data": "你的业务数据"
  }
  

• 创建 Notification Service Extension，在 didReceive(_:withContentHandler:) 方法里处理自定义数据。即便应用完全关闭，系统也会唤醒这个扩展来执行代码（注意扩展的运行时长上限约30秒，只能做轻量操作）。

2. 严格遵循 APNs 后台推送规范 #

确保推送的请求头和 payload 完全符合苹果的要求：

• 请求头必须设置 apns-push-type: background（iOS 13+ 强制要求）
• payload 仅保留 content-available: 1，不能包含 alert、sound、badge 这类会触发用户可见通知的字段
• 注意苹果对后台推送的频率有严格限流，过度推送会被系统拦截，导致无法触发。

3. 定位唤醒（仅限符合场景的应用） #

如果你的应用属于导航、运动这类需要持续定位的场景，可以申请「Always」定位权限，利用「显著位置变化服务」或「地理围栏监测」来唤醒应用，之后再拉取数据替代静默推送的作用。但这个方案仅限合规场景，滥用会导致审核被拒。

4. 检查 FCM 配置细节 #

• 推送优先级要设置正确：后台推送需对应 APNs 的 apns-priority: 5（不要用高优先级的10，那是给即时通知用的）
• 确保 FCM 正确传递了 content-available 字段，有时候直接指定 APNs 原生 payload 会更可靠：

  // FCM 发送时的原生 APNs payload 示例
  let apnsMessage = APNSMessage(token: deviceApnsToken, payload: [
    "aps": [
      "content-available": 1,
      "apns-push-type": "background"
    ],
    "business_data": "你的自定义数据"
  ])
  Messaging.messaging().send(apnsMessage)
  

需要注意的是，苹果在 iOS 14+ 对后台唤醒的管控非常严格，即使用了上述方案，也无法保证100%触发——系统会根据用户的应用使用频率、设备电量等因素动态调整推送的触发概率。

内容的提问来源于stack exchange，提问作者Empiric10