WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Meet Push Notifications Console

Meet Push Notifications Console

System ServicesDeveloper Tools
观看原视频

Highlight

Apple 在 WWDC23 推出了 Push Notifications Console——一个网页端的推送通知调试工具，开发者可以直接在浏览器中向设备发送测试推送、查看通知的完整投递链路、生成和验证 APNs 认证令牌，不再需要为了测试一条推送而搭建后端服务或反复修改服务器代码。

核心内容

推送测试的痛点

调试推送通知一直是个麻烦事。典型的流程是这样的：修改 payload、提交服务器代码、部署、触发发送、等几秒、拿起手机看有没有收到。如果没收到，查日志、改 payload、再部署一遍。一个简单的 payload 格式调整可能耗费十几分钟。

另一种做法是用命令行工具如 curl 直接调 APNs HTTP/2 接口。这需要先搞定认证——要么生成 JWT 令牌（得自己算签名），要么准备好证书（得从 Keychain 导出 .p12 再转成 .pem）。每次令牌过期还得重新生成。

这两种方式的核心问题是：推送测试和服务器代码耦合在一起，反馈回路太长。

Push Notifications Console 是什么

Push Notifications Console 是 Apple 在 2023 年推出的网页工具，地址是 icloud.developer.apple.com 下的 Push Notifications 板块。它把推送测试拆成了三个独立功能：

  1. 发送测试通知——在网页界面填写 device token 和 payload，点一下发送
  2. 投递日志（Delivery Log）——查看每条通知经过 APNs 系统时触发的所有事件
  3. 令牌工具——生成、验证认证令牌，检查 device token 有效性

这三个功能各自独立，但组合起来覆盖了推送调试的完整流程。

详细内容

发送测试通知（00:30）

Console 提供了一个 Web 表单用于发送推送通知。你需要填写以下字段：

  • Device Token：目标设备的推送令牌，十六进制字符串格式
  • Payload：JSON 格式的通知内容，包括 aps 字典和自定义数据
  • 环境：Development 或 Production
  • 推送类型：alert、background、voip、complication、fileprovider、mdm 等
  • 过期时间：APNs 保留该通知的最长时间
  • 优先级：10（立即发送）或 5（省电模式发送）

一个典型的测试 payload 如下：

{
  "aps": {
    "alert": {
      "title": "新消息",
      "body": "你有一条来自张三的新消息"
    },
    "badge": 1,
    "sound": "default"
  },
  "custom_key": "custom_value"
}

发送后，侧边栏会保存发送历史。你可以点击历史中的任何一条记录，修改参数后重新发送。这对于需要反复调整 payload 的场景很有用。

关键点：

  • Device Token 通过 Xcode 控制台或 App 中 didRegisterForRemoteNotificationsWithDeviceToken 回调获取
  • 环境（Development/Production）必须与 App 的签名配置匹配，否则通知收不到
  • 发送历史保存在浏览器本地，不会跨设备同步

投递日志（02:00）

这是 Console 最实用的功能。每次通过 APNs 发送通知后，APNs 会返回一个 apns-unique-id 响应头。把这个 ID 粘贴到 Delivery Log 的搜索框中，就能看到通知经过 APNs 系统时的完整事件链。

事件链通常包含这些节点：

  • Received：APNs 收到了通知请求
  • Stored：通知被暂存（设备不在线或处于低电量模式）
  • Sent：通知已发送到设备
  • Delivered：通知已投递到设备
  • Discarded：通知被丢弃（过期或被更新的通知替换）
  • Error：投递失败，附带失败原因

每个事件都附带了为什么的解释。比如设备处于低电量模式时，通知会被标记为 Stored 并说明原因。设备恢复后，通知自动进入 Sent 状态。

这个功能不仅适用于通过 Console 发送的通知。只要你的服务端代码记录了 apns-unique-id，就可以用它来追踪任何通过 APNs API 发送的通知。

关键点：

  • apns-unique-id 是 APNs 返回的唯一标识符，服务端应记录到日志中
  • 投递日志的保留时间有限，建议及时查看
  • 事件链可以帮助区分”通知没到达 APNs”和”APNs 发了但设备没收到”两类问题

令牌工具（04:30）

Console 提供了三个与令牌相关的工具。

认证令牌生成器：输入 APNs 私钥（.p8 文件内容）、Key ID 和 Team ID，自动生成 JWT 格式的认证令牌。私钥只在浏览器中处理，不会上传到 Apple 服务器。

生成 JWT 的步骤是：

  1. 构造 header：{"alg": "ES256", "kid": "你的KeyID"}
  2. 构造 payload：{"iss": "TeamID", "iat": 当前时间戳}
  3. 用 ES256 算法对 header + payload 签名
  4. 输出格式：base64(header).base64(payload).base64(signature)

Console 把这个过程封装成了一个表单——填好三个字段，点生成，令牌就出来了。

认证令牌验证器：粘贴已有的 JWT 令牌，检查是否有效。如果无效，会给出具体原因，比如”签发时间过旧”或”签名不匹配”。

Device Token 验证器：检查一个 device token 是否有效，以及它属于 Development 还是 Production 环境。

关键点：

  • Token-based 认证的 JWT 有效期最长为 1 小时，服务端需要有轮换机制
  • 私钥文件（.p8）只在 Apple Developer 账户中下载一次，之后无法重新获取，需妥善保管
  • Device Token 在系统更新、App 重装后可能变化，服务端应处理 410（Unregistered）响应

核心启发

1. 在 CI 中加入推送端到端测试

做什么：在 CI/CD 流水线中加入推送通知的端到端测试步骤。

为什么值得做：现在有了 apns-unique-id，你可以在自动化测试中发送通知、记录 ID、然后在 Delivery Log 中验证投递结果。这比之前只能检查 HTTP 状态码要可靠得多。

怎么开始：在测试脚本中用 APNs API 发送测试通知，保存返回的 apns-unique-id。测试用例结束时，用这个 ID 查 Delivery Log 确认通知状态为 Delivered。

2. 做一个推送 payload 模板管理工具

做什么：在团队内部建立一个推送 payload 模板库，配合 Console 快速切换和测试不同模板。

为什么值得做：Console 支持保存和复制发送历史，但你可以在团队层面做得更好——分类管理 alert、background、voip 等不同场景的 payload，新人接入时直接复制模板。

怎么开始：从 App 实际用到的通知类型出发，整理 5-10 个标准 payload 模板。每个模板标注适用的推送类型、优先级和过期时间。

3. 为运营推送建立监控面板

做什么：搭建一个实时监控面板，追踪运营推送的投递成功率。

为什么值得做：apns-unique-id 让每条推送都可追踪。你可以建立从服务端日志到 Delivery Log 的链路，监控推送的到达率、延迟和失败原因。

怎么开始：在推送发送服务中记录 apns-unique-id 和对应的消息 ID。定期（如每小时）用脚本批量检查投递状态，统计成功率。

4. 用 Console 做推送 A/B 测试原型

做什么：在正式开发 A/B 测试系统前，用 Console 快速验证不同 payload 的效果。

为什么值得做：Console 的发送历史让重复发送变体变得简单。你可以手动发送几个不同版本的 payload，在设备上观察展示效果，确定最优格式后再写代码。

怎么开始：设计 3-4 种不同风格的 alert 文案（长度、语气、action 文案），在 Console 中依次发送到同一台设备，截图对比。

关联 Session

评论

GitHub Issues · utterances