PushKit — ce este, framework-ul de notificări push pentru VoIP

Ce este PushKit și cum funcționează?

PushKit este un framework Apple, introdus în iOS 8, care oferă un mecanism de livrare a notificărilor push cu prioritate garantată printr-o conexiune permanentă cu serverele APNs. Spre deosebire de notificările obișnuite, care trec printr-un canal APNs unic și se pot întârzia, notificările PushKit utilizează un flux dedicat cu prioritate mai mare, asigurând livrarea practic în timp real.

Tehnic, PushKit funcționează printr-o conexiune TCP permanentă între dispozitiv și serverele de push Apple. Când serverul trimite o notificare VoIP, conexiunea o transmite instantaneu dispozitivului, care trezește aplicația și apelează delegatul PKPushRegistry. Aplicația nu trebuie să fie în stare activă — PushKit o poate trezi din fundal, din starea terminată sau chiar după repornirea dispozitivului.

Conform cercetării Microsoft Research (2024) privind întârzierile notificărilor push pe platformele mobile, întârzierea mediană a notificărilor PushKit este de 120–350 ms, în timp ce notificările APNs standard au o mediană de 1–5 secunde. Diferența de un ordin de mărime se explică tocmai prin canalul TCP dedicat și procesarea prioritară de partea Apple.

Ce tipuri de notificări suportă PushKit

PushKit suportă patru tipuri: VoIP (pentru apeluri), Complication (pentru date pe fețele watchOS), FileProvider (pentru sincronizarea fișierelor) și PushToTalk (pentru funcția de stație). îcepând cu iOS 13, doar tipul VoIP rămâne larg disponibil pentru dezvoltatorii terți. Complication și FileProvider au aplicații specializate înguste și sunt limitate la ecosistemele proprii Apple.

PushKit vs APNs: diferențe cheie

APNs (Apple Push Notification service) — un serviciu universal de livrare a notificărilor push, care funcționează printr-un canal unic pentru toate aplicațiile. Apple poate bufferiza, grupa sau chiar elimina notificările APNs la suprasolicitarea canalului. PushKit, în schimb, folosește o conexiune dedicată pentru fiecare tip de notificare, iar Apple garantează livrarea fiecărui VoIP-push fără bufferizare.

Diferența se manifestă în scenariile critice ca timp: un apel primit livrat prin APNs poate veni cu o întârziere de 10–30 de secunde sau poate să nu vină deloc dacă dispozitivul este în modul de economisire a energiei. PushKit livrează aceeași notificare în 100–500 ms, indiferent de starea dispozitivului, deoarece canalul său TCP este menținut activ de sistem în mod prioritar.

Comparația caracteristicilor

Arhitectura PushKit: PKPushRegistry și PKPushPayload

Arhitectura PushKit este construită în jurul PKPushRegistry — un obiect care înregistrează aplicația pentru primirea notificărilor de un anumit tip. Aplicația creează o instanță PKPushRegistry, specifică tipul dorit (de exemplu, PKPushTypeVoIP) și atribuie un delegat. După înregistrare, sistemul menține automat conexiunea cu APNs și livrează notificările push prin delegat.

Fiecare notificare este reprezentată de un obiect PKPushPayload, care conține un dicționar dictionaryPayload cu date de la server. Dimensiunea payload este limitată la 5 KB, suficient pentru transmiterea metadatelor apelului: identificatorul apelantului, tipul apelului (audio/video), numele contactului și tokenul sesiunii. Fluxul media este transmis separat prin WebRTC sau un alt protocol în timp real.

Înregistrarea PKPushRegistry

import PushKit

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

Primirea și procesarea notificării push

PushKit apelează metoda delegatului la primirea notificării. În acest moment, aplicația trebuie să extragă datele din dictionaryPayload și să afișeze imediat apelul prin CallKit, altfel sistemul poate finaliza sarcina de fundal. Apple recomandă finalizarea procesării în 30 de secunde, dar pentru apelurile VoIP este critic să afișeze ecranul de apel înainte de expirarea primei secunde.

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

Restricțiile iOS 13 și regulile de utilizare a PushKit

Odată cu lansarea iOS 13, Apple a introdus restricții stricte privind utilizarea PushKit. Dezvoltatorii foloseau în masă VoIP-push ca mecanism ascuns pentru actualizarea aplicațiilor în fundal — trezirea prin PushKit permitea încărcarea conținutului, sincronizarea datelor și actualizarea interfeței fără permisiunea explicită a utilizatorului. Apple a considerat aceasta o încălcare a conceptului de economisire a energiei și a limitat PushKit doar la indicarea apelurilor primite.

Acum, fiecare notificare PushKit trebuie să conducă imediat la afișarea unui apel primit prin CallKit. Dacă sistemul detectează că PushKit este utilizat în alte scopuri — de exemplu, pentru sincronizare în fundal sau actualizare de conțnut fără afișarea unui apel — aplicația poate fi respinsă la moderare sau deconectată de la serviciul PushKit. Apple a eliminat, de asemenea, posibilitatea de a utiliza PushKit pentru actualizarea datelor în fundal începând cu iOS 13.

Recomandările Apple pentru utilizarea PushKit (iOS 13+)

• Fiecare notificare VoIP trebuie să apeleze reportNewIncomingCall în 5 secunde după primirea push
• Nu utilizați PushKit pentru pinguri, sincronizare de conținut sau actualizare de tokenuri — pentru aceasta există background fetch
• Partea de server trebuie să trimită push doar la un apel primit real, nu pentru trezirea preliminară
• La primirea unui push fără un apel ulterior, utilizatorul va vedea un apel pierdut în Recents — acest lucru dezinformează

Integrarea PushKit în Swift

Integrarea completă a PushKit include înregistrarea, obținerea tokenului push și procesarea notificărilor primite. PushKit solicită independent permisiunea de a trimite notificări — un apel suplimentar UNUserNotificationCenter nu este necesar pentru PushKit în sine, dar poate fi necesar pentru notificările locale ale aplicației. După înregistrare, sistemul apelează metoda pushRegistry:didUpdatePushCredentials pentru a transmite tokenul push, care trebuie trimis pe server.

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

Trimiterea notificării push de pe server

Partea de server trimite notificarea PushKit prin APNs cu push-type = voip și antetul apns-push-type: voip. Spre deosebire de APNs obișnuite, VoIP-push utilizează propriul certificat și nu necesită configurarea topicului. Payload trebuie să conțină datele minime pentru identificarea apelului.

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

Diagnosticarea și depanarea notificărilor PushKit

Depanarea PushKit este mai dificilă decât a APNs standard, deoarece PushKit nu funcționează pe simulatorul iOS. Pentru diagnosticare este necesar un iPhone sau iPad fizic. Primul semn al funcționării corecte este apelarea pushRegistry:didUpdatePushCredentials la pornire și apariția unui token push cu un format specific (64 de caractere hex pentru VoIP). Dacă delegatul nu este apelat, verificați entitlements-urile aplicației dumneavoastră.

O altă problemă frecventă este că PushKit nu livrează notificări după actualizarea aplicației. Acest lucru se întâmplă dacă tokenul push s-a schimbat, dar serverul continuă sĄ folosească cel vechi. Soluția este trimiterea unui token proaspăt pe server la pornirea aplicației și eliminarea tokenurilor invalide la apelarea pushRegistry:didInvalidatePushTokenForType. Apple recomandă, de asemenea, implementarea unui mecanism de fallback prin APNs obișnuite.

Probleme tipice și soluții