WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Broadcast updates to your Live Activities

Broadcast updates to your Live Activities

WWDC 2024
元の動画を見る

ハイライト

iOS 18 で Broadcast Push Notifications が導入され、サーバーがチャンネル（Channel）経由で 1 回のプッシュを送るだけで、そのチャンネルを購読するすべての Live Activity を一括更新できます。token ごとの送信は不要になりました。

主要内容

サッカーの試合、10 万人が同時にスコアを見ています。各人の iPhone に Live Activity があり、各 Live Activity には独立した push token があります。サーバーがやることは単純——同じスコア更新を全員にプッシュすることです。旧プッシュモデルでは token ごとの送信が必要でした。10 万 token を保存し、APNs を 10 万回ループし、payload はまったく同じです。

iOS 18 の Broadcast Push Notifications がこのスケール問題を解決します。核心概念は Channel（チャンネル）で、テレビ放送に似ています。1 チャンネルが 1 イベントに対応し、そのチャンネルを購読するすべてのデバイスが同時に同じプッシュを受け取ります。サーバーは 1 回リクエストするだけで、APNs がすべての購読者へ配信します。

フローは 3 段階です。第一に Developer Portal で Broadcast Capability を有効化し、チャンネルを作成して channel ID を取得。第二に app 側で Live Activity 起動時に pushType: .channel(channelId) でチャンネルを購読。第三にサーバーからチャンネルへブロードキャストプッシュを送信。テスト用には Push Notifications Console で手動作成も可能で、本番環境ではサーバーが APNs チャンネル管理 API を直接呼び出します。

詳細

Broadcast Capability の有効化

Developer Portal の app Capabilities 一覧で、Push Notifications の下に Broadcast トグルが追加されています。これをオンにすると app がチャンネル機能を使えます（00:14）。

チャンネルの作成

開発段階では Push Notifications Console を使用します。Channels タブで New Channel をクリック。2 項目を設定します：環境とメッセージ保存ポリシー（01:41）。

メッセージ保存ポリシーは 2 種類です：

  • No Storage：その時オンラインのデバイスにのみ配信。オフラインメッセージは保存しませんが、より高い送信クォータが許可されます。試合スコアなど高頻度更新向け。
  • Most Recent Message：オフラインデバイスごとに最新 1 件を保存し、再接続時に配信。フライト状態など低頻度だが重要なシナリオ向け。

作成後、チャンネルには base64 エンコードのランダム channel ID が割り当てられます。本番環境ではサーバーが APNs Channel Management API で作成します（04:58）。

チャンネルの購読

app 側では Live Activity 起動時に channel push type を指定します：

// Request a Live Activity and subscribe to broadcast push notifications

import ActivityKit

func startLiveActivity(channelId: String) {
    let gameAttributes = GameAttributes()
    let initialState = GameAttributes.ContentState(
            home: 0, away: 0, update: "First Half"
    )
    try Activity.request(
            attributes: gameAttributes,
            content: .init(state: initialState, staleDate: nil),
            pushType: .channel(channelId)
    )
}

キーポイント:

  • channelId はサーバーが事前に作成し、Live Activity 起動前に app がサーバーから取得します
  • pushType: .channel(channelId) は ActivityKit にそのチャンネルのブロードキャストプッシュを購読させ、従来の .token 方式に代わります
  • 呼び出し後、ActivityKit が APNs にそのチャンネルへのデバイス購読を自動登録します。push token の手動管理は不要です
  • チャンネルのライフサイクルは Live Activity と独立します。ユーザーが Live Activity を閉じてもチャンネルは残り、後続の Live Activity が引き続き購読できます

ブロードキャストプッシュの送信

テスト段階では Push Notifications Console で操作：チャンネル選択 → New Notification → 優先度と payload 入力 → Send。1 回のプッシュで、すべての購読デバイスが同時に更新を受け取ります（07:47）。

本番環境では新しい APNs API で送信し、認証方式は既存 APNs 接続と同じ（証明書または token）です。payload 形式は通常の Live Activity プッシュと同じで、content-state 内の更新データとタイムスタンプを含みます。

チャンネルライフサイクル管理

チャンネル総数には上限があります。イベント終了後、サーバーは Channel Management API で不要なチャンネルを削除すべきです。例えば試合終了後にその試合用チャンネルを削除し、クォータを解放します（10:18）。

重要ポイント

  1. スポーツ試合のリアルタイムスコアプッシュ：各試合に 1 チャンネルを作成し、ユーザーがフォローをタップするとそのチャンネルを購読。スコア変化時に 1 回のブロードキャストプッシュで全員の Live Activity を更新。なぜ価値があるか：万単位 push token の保存・管理コストを省き、遅延を「逐次送信」から「1 回のブロードキャスト」へ短縮。どう始めるか：サーバーで Channel Management API を呼んでチャンネル作成、app 側は .channel(channelId) で Live Activity 起動。

  2. フライト状態追跡：各フライト番号に 1 チャンネル。乗客が自分のフライトチャンネルを購読し、ゲート変更・遅延・欠航などを受信。なぜ価値があるか：同一フライトの全乗客の状態は同じで、ブロードキャストプッシュが自然にマッチ。Most Recent Message ポリシーでオフライン乗客も再接続時に最新状態を受信。どう始めるか：チャンネル作成時に Most Recent Message 保存ポリシーを選択。離陸または欠航後にチャンネル削除。

  3. 複数者協調タスクのリアルタイム状態同期：例えば配達プラットフォームのライダー位置共有——同一注文の複数者（注文者、ライダー、店舗）が同一チャンネルを購読し、位置更新時に 1 回のブロードキャストプッシュですべての関係者へ同期。なぜ価値があるか：ユーザーごとに独立 push token を維持するより、チャンネルモードで N 回のプッシュを 1 回に統合。どう始めるか：注文時にチャンネル作成、app は channel ID で Live Activity 起動、ライダー側が位置更新時にチャンネルへブロードキャストプッシュ。

関連セッション

コメント

GitHub Issues · utterances