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

Meet Push Notifications Console

System ServicesDeveloper Tools
元の動画を見る

ハイライト

WWDC23 で Apple は Push Notifications Console を発表しました。これはブラウザ上でプッシュ通知をデバッグするための Web ツールです。開発者はブラウザから直接テストプッシュを送信し、通知の完全な配信チェーンを確認し、APNs 認証トークンの生成と検証を行えます。1 本のプッシュを試すためにバックエンドを立てたり、サーバーコードを何度も書き換えたりする必要はありません。

主要内容

プッシュテストの課題

プッシュ通知のデバッグは、これまでずっと面倒でした。典型的な流れはこうです。payload を変更し、サーバーコードをコミットし、デプロイし、送信をトリガーし、数秒待ち、スマートフォンを手に取って届いたか確認する。届かなければログを調べ、payload を直し、またデプロイする。単純な payload 形式の調整でも、10〜15 分は簡単にかかります。

別の方法として、curl などのコマンドラインツールで APNs HTTP/2 API を直接呼ぶこともできます。ただし、その前に認証を整える必要があります。JWT トークンを生成する（署名も自分で計算する）か、証明書を用意する（Keychain から .p12 を書き出して .pem に変換する）かです。トークンの有効期限が切れるたびに、また生成し直します。

どちらの方法にも共通する根本的な問題があります。プッシュテストがサーバーコードと結びついており、フィードバックループが長すぎるということです。

Push Notifications Console とは

Push Notifications Console は Apple が 2023 年に公開した Web ツールで、icloud.developer.apple.com の Push Notifications セクションにあります。プッシュテストを 3 つの独立した機能に分けています。

  1. テスト通知の送信 — Web UI で device token と payload を入力して送信
  2. Delivery Log（配信ログ） — 通知が APNs を通過する際に発生したすべてのイベントを表示
  3. トークンツール — 認証トークンの生成・検証、device token の有効性チェック

各機能は単体でも使えますが、組み合わせるとプッシュデバッグの一連の流れをカバーできます。

詳細

テスト通知の送信（00:30）

Console にはプッシュ通知を送るための Web フォームがあります。次の項目を入力します。

  • Device Token: 対象デバイスのプッシュトークン（16 進文字列）
  • Payload: aps 辞書とカスタムデータを含む JSON 形式の通知内容
  • Environment: Development または Production
  • Push Type: alert、background、voip、complication、fileprovider、mdm など
  • Expiration: APNs が通知を保持する最長時間
  • Priority: 10（即時送信）または 5（省電力モード向け送信）

典型的なテスト payload は次のとおりです。

{
  "aps": {
    "alert": {
      "title": "新着メッセージ",
      "body": "張三さんから新しいメッセージが届いています"
    },
    "badge": 1,
    "sound": "default"
  },
  "custom_key": "custom_value"
}

送信後、サイドバーに送信履歴が残ります。履歴の任意の項目をクリックしてパラメータを変更し、再送信できます。payload の形を何度も試す場面で特に便利です。

キーポイント:

  • device token は Xcode コンソール、または App の didRegisterForRemoteNotificationsWithDeviceToken コールバックから取得します
  • Environment（Development/Production）は App の署名設定と一致している必要があります。一致しないと通知は届きません
  • 送信履歴はブラウザのローカルに保存され、デバイス間では同期されません

Delivery Log（02:00）

Console で最も実用的な機能です。APNs 経由で送信するたびに、APNs は apns-unique-id レスポンスヘッダーを返します。この ID を Delivery Log の検索ボックスに貼り付けると、その通知が APNs を通過した際の完全なイベントチェーンが表示されます。

チェーンには通常、次のノードが含まれます。

  • Received: APNs が通知リクエストを受信
  • Stored: 通知がキューに入った（デバイスがオフライン、または低電力モード）
  • Sent: 通知がデバイスに送信された
  • Delivered: 通知がデバイスに配信された
  • Discarded: 通知が破棄された（期限切れ、または新しい通知に置き換え）
  • Error: 配信失敗（理由付き）

各イベントには、なぜその状態になったかの説明が付きます。たとえばデバイスが低電力モードのとき、通知は理由付きで Stored とマークされます。デバイスが復帰すると、通知は Sent に移ります。

Console から送った通知だけでなく、APNs API 経由で送ったものにも使えます。サーバーコードで apns-unique-id を記録していればよいのです。

キーポイント:

  • apns-unique-id は APNs が返す一意の識別子です。サーバー側でログに残すべきです
  • 配信ログの保持期間は限られているため、結果は早めに確認してください
  • イベントチェーンは「通知が APNs に届いていない」と「APNs は送ったがデバイスが受け取っていない」を切り分けるのに役立ちます

トークンツール（04:30）

Console にはトークン関連のツールが 3 つあります。

認証トークン生成器: APNs 秘密鍵（.p8 ファイルの内容）、Key ID、Team ID を入力すると、JWT 形式の認証トークンを自動生成します。秘密鍵はブラウザ内でのみ処理され、Apple サーバーにはアップロードされません。

JWT 生成の手順は次のとおりです。

  1. ヘッダーを構築: {"alg": "ES256", "kid": "yourKeyID"}
  2. payload を構築: {"iss": "TeamID", "iat": currentTimestamp}
  3. header + payload を ES256 で署名
  4. 出力形式: base64(header).base64(payload).base64(signature)

Console はこれをフォームにまとめています。3 つの項目を入力して Generate をクリックすれば、トークンが表示されます。

認証トークン検証器: 既存の JWT を貼り付けて有効かどうかを確認します。無効な場合は「発行から時間が経ちすぎている」「署名が一致しない」など、具体的な理由が表示されます。

Device Token 検証器: device token が有効かどうか、Development 環境か Production 環境かを確認します。

キーポイント:

  • トークンベース認証の JWT は最長 1 時間有効です。サーバー側にローテーションの仕組みが必要です
  • 秘密鍵（.p8）は Apple Developer アカウントから一度だけダウンロードできます。安全に保管してください
  • device token は OS アップデートや App の再インストール後に変わることがあります。サーバーは 410（Unregistered）レスポンスを処理する必要があります

重要ポイント

1. CI にプッシュの E2E テストを追加する

やること: 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 などシナリオ別にテンプレートを整理すれば、新メンバーはコピーするだけで始められます。

始め方: App が実際に使う通知タイプから、5〜10 個の標準 payload テンプレートを用意する。各テンプレートに想定する Push Type、優先度、有効期限を明記する。

3. 運用プッシュ向けモニタリングダッシュボードを構築する

やること: 運用プッシュの配信成功率を追跡するリアルタイムダッシュボードを構築する。

価値: apns-unique-id により、すべてのプッシュが追跡可能になります。サーバーログと Delivery Log をつなぎ、到達率・遅延・失敗理由を監視できます。

始め方: プッシュ送信サービスで apns-unique-id と対応するメッセージ ID を記録する。定期的（たとえば 1 時間ごと）にスクリプトで配信ステータスを一括確認し、成功率を集計する。

4. Console でプッシュ A/B テストのプロトタイプを作る

やること: 本格的な A/B テスト基盤を作る前に、Console で異なる payload バリアントを素早く検証する。

価値: 送信履歴があるので、バリアントの再送信が簡単です。同じデバイスに複数バージョンの payload を手動送信し、表示を確認してから最適な形式を決め、コードに着手できます。

始め方: 3〜4 種類の alert 文案（長さ、トーン、アクションテキスト）を設計し、Console から同じデバイスに順番に送信して、スクリーンショットで比較する。

関連セッション

コメント

GitHub Issues · utterances