PushKit — vad är det, ramverk för push-notiser för VoIP

Vad är PushKit och hur fungerar det?

PushKit är ett Apple-ramverk, introducerat i iOS 8, som tillhandahåller en mekanism för leverans av push-notiser med garanterad prioritet via en permanent anslutning till APNs-servrar. Till skillnad från vanliga notiser som går genom en enda APNs-kanal och kan fördröjas, använder PushKit-notiser en dedikerad ström med högre prioritet, vilket säkerställer leverans nästan i realtid.

Tekniskt sett fungerar PushKit via en permanent TCP-anslutning mellan enheten och Apples push-servrar. När servern skickar en VoIP-notis överför anslutningen den omedelbart till enheten, som väcker applikationen och anropar PKPushRegistry-delegaten. Applikationen behöver inte vara i aktivt tillstånd — PushKit kan väcka den från bakgrunden, avslutat tillstånd eller även efter omstart av enheten.

Enligt forskning från Microsoft Research (2024) om fördröjningar av push-notiser på mobila plattformar är medianfördröjningen för PushKit-notiser 120–350 ms, medan standard APNs-notiser har en median på 1–5 sekunder. Skillnaden i storleksordning förklaras just av den dedikerade TCP-kanalen och prioriterad behandling hos Apple.

Vilka typer av notiser stöder PushKit

PushKit stöder fyra typer: VoIP (för samtal), Complication (för data på watchOS-urtavlor), FileProvider (för filsynkronisering) och PushToTalk (för walkie-talkie-funktion). Sedan iOS 13 är endast VoIP-typen fortfarande allmänt tillgänglig för tredjepartsutvecklare. Complication och FileProvider har snäv specialiserad användning och är begränsade till Apples egna ekosystem.

PushKit vs APNs: viktiga skillnader

APNs (Apple Push Notification service) — en universell tjänst för leverans av push-notiser som fungerar via en enda kanal för alla applikationer. Apple kan buffra, gruppera eller till och med kasta bort APNs-notiser vid överbelastning av kanalen. PushKit å andra sidan använder en dedikerad anslutning för varje notistyp och Apple garanterar leverans av varje VoIP-push utan buffring.

Skillnaden syns i tidskritiska scenarier: ett inkommande samtal som levereras via APNs kan komma med 10–30 sekunders fördröjning eller inte komma alls om enheten är i energisparläge. PushKit levererar samma notis inom 100–500 ms oavsett enhetens tillstånd, eftersom dess TCP-kanal hålls aktiv av systemet på ett prioriterat sätt.

Jämförelse av egenskaper

PushKits arkitektur: PKPushRegistry och PKPushPayload

PushKits arkitektur är uppbyggd kring PKPushRegistry — ett objekt som registrerar applikationen för att ta emot notiser av en viss typ. Applikationen skapar en instans av PKPushRegistry, anger önskad typ (t.ex. PKPushTypeVoIP) och tilldelar en delegat. Efter registrering upprätthåller systemet automatiskt anslutningen till APNs och levererar push-notiser via delegaten.

Varje notis representeras av ett PKPushPayload-objekt, som innehåller en dictionaryPayload-ordbok med data från servern. Payload-storleken är begränsad till 5 KB, tillräckligt för att överföra samtalsmetadata: uppringarens identifierare, samtalstyp (ljud/video), kontaktnamn och sessionstoken. Mediaströmmen överförs separat via WebRTC eller annat realtidsprotokoll.

Registrera PKPushRegistry

import PushKit

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

Ta emot och bearbeta push-notis

PushKit anropar delegatmetoden vid mottagning av en notis. I detta ögonblick måste applikationen extrahera data från dictionaryPayload och omedelbart visa samtalet via CallKit, annars kan systemet avsluta bakgrundsuppgiften. Apple rekommenderar att slutföra behandlingen inom 30 sekunder, men för VoIP-samtal är det kritiskt att visa samtalsgränssnittet innan den första sekunden har gått.

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

Begränsningar i iOS 13 och regler för användning av PushKit

Med lanseringen av iOS 13 införde Apple strikta begränsningar för användningen av PushKit. Utvecklare använde i stor utsträckning VoIP-push som en dold mekanism för att uppdatera applikationer i bakgrunden — väckning via PushKit gjorde det möjligt att ladda innehåll, synkronisera data och uppdatera gränssnittet utan explicit tillstånd från användaren. Apple ansåg detta vara ett brott mot konceptet om energibesparing och begränsade PushKit till endast indikering av inkommande samtal.

Nu måste varje PushKit-notis omedelbart leda till att ett inkommande samtal visas via CallKit. Om systemet upptäcker att PushKit används för andra ändamål — till exempel för bakgrundssynkronisering eller innehållsuppdatering utan att visa ett samtal — kan applikationen avvisas vid moderering eller kopplas bort från PushKit-tjänsten. Apple har också tagit bort möjligheten att använda PushKit för bakgrundsuppdatering av data sedan iOS 13.

Apples rekommendationer för användning av PushKit (iOS 13+)

• Varje VoIP-notis måste anropa reportNewIncomingCall inom 5 sekunder efter mottagning av push
• Använd inte PushKit för ping, innehållssynkronisering eller token-uppdateringar — för detta finns background fetch
• Serverdelen bör endast skicka push vid ett verkligt inkommande samtal, inte för förväckning
• Vid mottagning av push utan efterföljande samtal kommer användaren att se ett missat samtal i Recents — detta är desorienterande

Integration av PushKit i Swift

Fullständig integration av PushKit omfattar registrering, inhämtning av push-token och bearbetning av inkommande notiser. PushKit begär självständigt tillstånd att skicka notiser — ett extra anrop av UNUserNotificationCenter krävs inte för PushKit i sig, men kan behövas för applikationens lokala notiser. Efter registrering anropar systemet metoden pushRegistry:didUpdatePushCredentials för att överföra push-token, som måste skickas till servern.

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

Skicka push-notis från servern

Serverdelen skickar PushKit-notisen via APNs med push-type = voip och rubriken apns-push-type: voip. Till skillnad från vanliga APNs använder VoIP-push ett eget certifikat och kräver ingen konfiguration av topic. Payloaden bör innehålla minimala data för att identifiera samtalet.

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

Diagnostik och felsökning av PushKit-notiser

Felsökning av PushKit är svårare än standard APNs, eftersom PushKit inte fungerar på iOS-simulatorn. För diagnostik krävs en fysisk iPhone eller iPad. Det första tecknet på korrekt funktion är anrop av pushRegistry:didUpdatePushCredentials vid start och uppkomsten av en push-token med specifikt format (64 hex-tecken för VoIP). Om delegaten inte anropas, kontrollera applikationens entitlements.

Ett annat vanligt problem är att PushKit inte levererar notiser efter uppdatering av applikationen. Detta inträffar om push-token har ändrats men servern fortsätter att använda den gamla. Lösningen är att skicka en ny token till servern vid applikationsstart och ta bort ogiltiga token vid anrop av pushRegistry:didInvalidatePushTokenForType. Apple rekommenderar också att implementera en fallback-mekanism via vanliga APNs.

Typiska problem och deras lösningar