PushKit — その概要、VoIP用push通知フレームワーク

PushKitとは何か、どのように動作するか

PushKitは、iOS 8で導入されたAppleのフレームワークで、APNsサーバーへの持続接続を通じて保証された優先度でpush通知を配信するメカニズムを提供します。単一のAPNsチャネルを通じて遅廰する可能性のある一般的な通知とは異なり、PushKit通知はより高い優先度の専用ストリームを使用し、実質的にリアルタイムの配信を保証します。

技術的に、PushKitはデバイスとAppleのpushサーバーの間の持続的なTCP接続を通じて動作します。サーバーがVoIP通知を送信すると、接続が即時にそれをデバイスに配信し、アプリケーションを起動してPKPushRegistryデリゲートを呼び出します。アプリケーションはアクティブ状態である必要はありません—PushKitはバックグラウンド、終了状態、またはデバイスのリブート後でも起動できます。

Microsoft Research (2024)によるモバイルプラットフォームにおけるpush通知遅廰の調査によると、PushKit通知の中央値は120–350msであるのに対し、標準APNs通知の中央値は1–5秒です。この複数段の違いは、専用TCPチャネルとApple側での優先処理によって説明されます。

PushKitはどんな通知タイプをサポートしていますか

PushKitは4つのタイプをサポートしています: VoIP（通話用）、Complication（時計の目屋データ用）、FileProvider（ファイル同期用）、およびPushToTalk（トーク機能用）。iOS 13以降、サードパーティ開発者が広く利用できるのはVoIPタイプだけです。ComplicationとFileProviderは専門的な用途で、Apple自体のエコシステムに制限されています。

PushKit vs APNs: 主な違い

APNs（Apple Push Notification service）は、すべてのアプリケーションに対して単一のチャネルを通じて動作する汎用push通知配信サービスです。チャネルが混雑しているとき、AppleはAPNs通知をバッファリング、グループ化、または棄徃することがあります。一方、PushKitは通知タイプごとに専用接続を使用し、Appleはバッファリングなしで毎回のVoIP pushの配信を保証します。

この違いは、時間クリティカルなシナリオで明確になります: APNsを通じて配信された入力通話は10–30秒の遅廰が生じたり、デバイスが低消費電力モードの場合はまったく届かないことがあります。PushKitは、TCPチャネルがシステムによって優先的にアクティブに保たれているため、デバイスの状態に関わらず、100–500msで同じ通知を配信します。

機能比較

PushKitのアーキテクチャ: PKPushRegistryとPKPushPayload

PushKitのアーキテクチャはPKPushRegistryを中心に構築されています—このオブジェクトは、特定のタイプの通知を受け取るようにアプリケーションを登録します。アプリケーションはPKPushRegistryのインスタンスを作成し、希望するタイプ（例えばPKPushTypeVoIP）を指定し、デリゲートを割り当てます。登録後、システムは自動的にAPNsとの接続を維持し、デリゲートを通じてpush通知を配信します。

各通知はPKPushPayloadオブジェクトで表現され、サーバーデータを含むdictionaryPayloadを保持します。payloadサイズは5KBに制限されていますが、通話メタデータ（呼出先識別子、通話タイプ（音声/ビデオ）、連絡先名、セッショントークン）を伝送するのに十分です。メディアストリームそのものは、WebRTCまたは他のリアルタイムプロトコルを通じて別途伝送されます。

PKPushRegistryの登録

import PushKit

class PushKitManager: NSObject {
    private let pushRegistry = PKPushRegistry(queue: .main)
    
    func configure() {
        pushRegistry.delegate = self
        pushRegistry.desiredPushTypes = [.voIP]
    }
}

Push通知の受信と処理

PushKitは通知受信時にデリゲートメソッドを呼び出します。この時点で、アプリケーションはdictionaryPayloadからデータを抽出し、CallKitを通じて即時に通話を表示する必要があります。そうしないと、システムがバックグラウンドタスクを終了する可能性があります。Appleは30秒以内の処理完了を推奨していますが、VoIP通話の場合は最初の秒で通話画面を表示することが重要です。

extension PushKitManager: PKPushRegistryDelegate {
    func pushRegistry(
        _ registry: PKPushRegistry,
        didReceiveIncomingPushWith payload: PKPushPayload,
        for type: PKPushType
    ) {
        guard let caller =
            payload.dictionaryPayload["caller"] as? String
        else { return }
        
        CallKitManager.shared.reportIncomingCall(
            uuid: UUID(),
            handle: caller
        )
    }
}

iOS 13の制限とPushKit使用ルール

iOS 13のリリースに伴い、AppleはPushKitの使用に関して厳格な制限を導入しました。開発者たちは、バックグラウンドのアプリ更新のための隠れたメカニズムとしてVoIP pushを広く使用していました—PushKitを通じた起動により、ユーザーの明示的な許可なしにコンテンツの読み込み、データの同期、インターフェースの更新が可能でした。Appleはこれを省電コンセプトの違反とみなし、PushKitを入力通話の通知のみに制限しました。

今では、毎回のPushKit通知は、CallKitを通じて即時に入力通話を表示する必覂があります。システムがPushKitが他の目的で使用されていることを検知した場合—例えば、通話を表示せずにバックグラウンドの同期またはコンテンツ更新—アプリケーションはレビュー中に拒否されたり、PushKitサービスから無効にされる可能性があります。AppleはiOS 13以降、バックグラウンドのデータ更新のためにPushKitを使用する機能も削除しました。

AppleによるPushKit使用の推奨事項 (iOS 13+)

• 毎回のVoIP通知は、push受信後5秒以内にreportNewIncomingCallを呼び出す必要があります
• ピング、コンテンツの同期、またはトークン更新にPushKitを使用しないでください—それらにはbackground fetchがあります
• サーバー側は、予備起動ではなく、実際に入力通話がある場合のみpushを送信する必要があります
• 続く通話なしでpushを受信すると、直近の筜略通話が表示されます—これはユーザーを迷惑させます

SwiftでのPushKit統合

PushKitの統合には、登録、pushトークンの取得、および入力通知の処理が含まれます。PushKitは自動的に通知送信の許可を要求します—PushKitそものにUNUserNotificationCenterの追加の呼び出しは必要ありませんが、アプリのローカル通知には必要な場合があります。登録後、システムはpushRegistry:didUpdatePushCredentialsを呼び出してpsuhトークンを届けます。このトークンはサーバーに送信する必要があります。

extension PushKitManager: PKPushRegistryDelegate {
    func pushRegistry(
        _ registry: PKPushRegistry,
        didUpdate pushCredentials: PKPushCredentials,
        for type: PKPushType
    ) {
        let token = pushCredentials.token
            .map { String(format: "%02x", $0) }
            .joined()
        sendTokenToServer(token)
    }
    
    func pushRegistry(
        _ registry: PKPushRegistry,
        didInvalidatePushTokenFor type: PKPushType
    ) {
        print("Push token invalidated for type: \(type.rawValue)")
    }
}

サーバーからのpush通知の送信

サーバー側は、push-type = voipとヘッダーapns-push-type: voipを使用してAPNsを通じてPushKit通知を送信します。一般的なAPNsとは異なり、VoIP pushは独自の証明書を使用し、トピックの設定は不要です。payloadには、通話を識別するための最小限のデータを含める必要があります。

// VoIP push payloadの例
{
    "aps": {
        "alert": {}
    },
    "caller": "+15551234567",
    "callerName": "Alice Johnson",
    "sessionId": "abc-123-def",
    "hasVideo": false
}

PushKit通知の診断とデバッグ

PushKitのデバッグは、標準のAPNsよりも複雑です、なぜならPushKitはiOSシミュレーターで動作しないからです。診断には、実物のiPhoneまたはiPadが必要です。正常動作の最初のサインは、起動時のpushRegistry:didUpdatePushCredentialsの呼び出しと、特定のフォーマット（VoIPの場合64つの16進文字）のpushトークンが表示されることです。デリゲートが呼び出されない場合は、アプリのentitlementsを確認してください。

もう一つのよくある問題は、アプリ更新後にPushKitが通知を配信しないことです。これは、pushトークンが変更されたが、サーバーが古いトークンを使用続けている場合に発生します。解決策は、アプリ起動時に新しいトークンをサーバーに送信し、pushRegistry:didInvalidatePushTokenForTypeが呼ばれたら無効なトークンを削除することです。Appleはまた、一般的なAPNsを通じたフォールバックメカニズムの実装も推奨しています。

よくある問題とその解決策