PushKit — qu’est-ce que c’est, le framework de notifications push pour VoIP

Qu’est-ce que PushKit et comment ça marche?

PushKit est un framework Apple présenté dans iOS 8 qui fournit un mécanisme de livraison de notifications push avec priorité garantie via une connexion persistante aux serveurs APNs. Contrairement aux notifications ordinaires qui passent par un seul canal APNs et peuvent être retardées, les notifications PushKit utilisent un flux dédié avec une priorité plus élevée, assurant une livraison quasi en temps réel.

Techniquement, PushKit fonctionne via une connexion TCP persistante entre l’appareil et les serveurs push d’Apple. Lorsqu’un serveur envoie une notification VoIP, la connexion la livre instantanément à l’appareil, qui réveille l’application et appelle le délégué PKPushRegistry. L’application n’a pas besoin d’être en état actif — PushKit peut la réveiller depuis l’arrière-plan, un état terminé ou même après un redémarrage de l’appareil.

Selon une étude de Microsoft Research (2024) sur la latence des notifications push sur les plateformes mobiles, la latence médiane des notifications PushKit est de 120–350 ms, tandis que les notifications APNs standard affichent une médiane de 1–5 secondes. La différence d’ordre de grandeur s’explique par le canal TCP dédié et le traitement prioritaire côté Apple.

Quels types de notifications PushKit prend-il en charge?

PushKit prend en charge quatre types: VoIP (pour les appels), Complication (pour les données de cadrans de montres), FileProvider (pour la synchronisation de fichiers) et PushToTalk (pour les fonctions talkie-walkie). Depuis iOS 13, seul le type VoIP reste largement disponible pour les développeurs tiers. Complication et FileProvider ont des applications de niche et sont limités aux propres écosystèmes d’Apple.

PushKit vs APNs: différences clés

APNs (Apple Push Notification service) est un service universel de livraison de notifications push fonctionnant via un seul canal pour toutes les applications. Apple peut mettre en mémoire tampon, regrouper ou même ignorer les notifications APNs lorsque le canal est congestionné. PushKit, en revanche, utilise une connexion dédiée pour chaque type de notification, et Apple garantit la livraison de chaque push VoIP sans mise en tampon.

La différence devient évidente dans les scénarios critiques en temps: un appel entrant livré via APNs peut arriver avec un retard de 10–30 secondes ou ne pas arriver du tout si l’appareil est en mode économie d’énergie. PushKit livre la même notification en 100–500 ms, quel que soit l’état de l’appareil, car son canal TCP est maintenu actif par le système en priorité.

Comparaison des caractéristiques

Architecture de PushKit: PKPushRegistry et PKPushPayload

L’architecture de PushKit est construite autour de PKPushRegistry — un objet qui enregistre l’application pour recevoir des notifications d’un type spécifique. L’application crée une instance de PKPushRegistry, spécifie le type souhaité (par exemple, PKPushTypeVoIP) et attribue un délégué. Après l’enregistrement, le système maintient automatiquement la connexion avec APNs et livre les notifications push via le délégué.

Chaque notification est représentée par un objet PKPushPayload, qui contient un dictionaryPayload avec les données du serveur. La taille du payload est limitée à 5 Ko, ce qui est suffisant pour transmettre les métadonnées de l’appel: identifiant de l’appelant, type d’appel (audio/vidéo), nom du contact et jeton de session. Le flux média lui-même est transmis séparément via WebRTC ou un autre protocole en temps réel.

Enregistrement de PKPushRegistry

import PushKit

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

Réception et traitement des notifications push

PushKit appelle la méthode déléguée lors de la réception d’une notification. À ce stade, l’application doit extraire les données du dictionaryPayload et afficher immédiatement l’appel via CallKit, sinon le système peut mettre fin à la tâche d’arrière-plan. Apple recommande de terminer le traitement dans les 30 secondes, mais pour les appels VoIP, il est crucial d’afficher l’écran d’appel dans la première seconde.

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
        )
    }
}

Restrictions iOS 13 et règles d’utilisation de PushKit

Avec la sortie d’iOS 13, Apple a introduit des restrictions strictes sur l’utilisation de PushKit. Les développeurs utilisaient massivement le push VoIP comme mécanisme caché pour les mises à jour d’applications en arrière-plan — le réveil via PushKit permettait de charger du contenu, de synchroniser des données et de mettre à jour l’interface sans autorisation explicite de l’utilisateur. Apple a considéré cela comme une violation du concept d’économie d’énergie et a limité PushKit à la seule indication d’appels entrants.

Désormais, chaque notification PushKit doit immédiatement aboutir à l’affichage d’un appel entrant via CallKit. Si le système détecte que PushKit est utilisé à d’autres fins — par exemple, synchronisation en arrière-plan ou mises à jour de contenu sans afficher d’appel — l’application peut être rejetée lors de l’examen ou désactivée du service PushKit. Apple a également supprimé la possibilité d’utiliser PushKit pour les mises à jour de données en arrière-plan à partir d’iOS 13.

Recommandations d’Apple pour l’utilisation de PushKit (iOS 13+)

• Chaque notification VoIP doit appeler reportNewIncomingCall dans les 5 secondes suivant la réception du push
• N’utilisez pas PushKit pour les pings, la synchronisation de contenu ou les mises à jour de jetons — il y a le background fetch pour cela
• Le côté serveur ne doit envoyer un push que lorsqu’il y a un véritable appel entrant, pas pour un réveil préalable
• Recevoir un push sans appel subsequent affichera un appel manqué dans Recents — cela désoriente l’utilisateur

Intégration de PushKit en Swift

L’intégration complète de PushKit comprend l’enregistrement, l’obtention d’un jeton push et le traitement des notifications entrantes. PushKit demande automatiquement l’autorisation d’envoyer des notifications — un appel supplémentaire à UNUserNotificationCenter n’est pas nécessaire pour PushKit lui-même, mais peut l’être pour les notifications locales de l’application. Après l’enregistrement, le système appelle pushRegistry:didUpdatePushCredentials pour délivrer le jeton push, qui doit être envoyé au serveur.

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)")
    }
}

Envoi de notifications push depuis le serveur

Le côté serveur envoie une notification PushKit via APNs avec push-type = voip et l’en-tête apns-push-type: voip. Contrairement aux APNs classiques, le push VoIP utilise son propre certificat et ne nécessite pas de configuration de topic. Le payload doit contenir des données minimales pour l’identification de l’appel.

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

Diagnostic et débogage des notifications PushKit

Le débogage de PushKit est plus complexe que celui des APNs standard car PushKit ne fonctionne pas sur le simulateur iOS. Un iPhone ou iPad physique est nécessaire pour le diagnostic. Le premier signe de bon fonctionnement est l’appel de pushRegistry:didUpdatePushCredentials au démarrage et l’apparition d’un jeton push dans un format spécifique (64 caractères hexadécimaux pour VoIP). Si le délégué n’est pas appelé, vérifiez les entitlements de votre application.

Un autre problème fréquent est que PushKit ne livre pas les notifications après une mise à jour de l’application. Cela se produit si le jeton push a changé mais que le serveur continue d’utiliser l’ancien. La solution est d’envoyer le nouveau jeton au serveur au démarrage de l’application et de supprimer les jetons invalides lorsque pushRegistry:didInvalidatePushTokenForType est appelé. Apple recommande également d’implémenter un mécanisme de secours via les APNs classiques.

Problèmes courants et leurs solutions