APNS: wat is het, architectuur van Apple Push Notification Service en hoe het werkt

Wat is APNS?

Apple Push Notification Service (APNS) — is Apples eigen dienst voor het routeren van pushmeldingen van de applicatieserver naar de apparaten van gebruikers. In tegenstelling tot FCM ondersteunt APNS geen Android of andere platforms — het is volledig gekoppeld aan het Apple-ecosysteem.

De dienst werkt via een permanente TLS-verbinding die elk Apple-apparaat bij het inschakelen tot stand brengt met de APNS-servers. Deze verbinding wordt op de achtergrond onderhouden en gebruikt voor het bezorgen van meldingen met minimale vertraging.

APNS neemt de volledige bezorginfrastructuur voor zijn rekening: encryptie, authenticatie, prioritering en opnieuw verzenden bij ontoegankelijkheid van het apparaat. De ontwikkelaar hoeft alleen een correct opgemaakte payload en een geldige push-token te verstrekken.

Evolutie van APNS

Aanvankelijk werkte APNS via een binaire protocol op poorten 2195–2196. Vanaf 2015 is Apple overgestapt op het moderne HTTP/2-protocol dat multiplexing, headercompressie en server-pushmeldingen ondersteunt. HTTP/2 is sinds juni 2020 verplicht.

Hoe werkt Apple Push Notification Service?

Het proces van het bezorgen van een pushmelding via APNS bestaat uit vijf fasen: registratie van het apparaat, verkrijgen van een push-token, verzenden van een verzoek door de server, routering door APNS en bezorging op het apparaat.

• Registratie — bij het starten roept de app registerForRemoteNotifications aan, het systeem verbindt zich met APNS
• Token — APNS retourneert een push-token aan het apparaat — een unieke tekenreeks die de app op het apparaat identificeert
• Verzenden — de applicatieserver stuurt een POST-verzoek naar https://api.push.apple.com met de token en payload
• Routering — APNS vindt het apparaat via de token en levert het bericht via de TLS-verbinding
• Verwerking — iOS/macOS toont de melding of geeft deze door aan de app, afhankelijk van de status

Als het apparaat ontoegankelijk is (uitgeschakeld of zonder netwerk), bewaart APNS het laatste bericht voor elke app en levert het bij herstel van de verbinding. De maximale bewaartermijn is 4 weken, daarna wordt het bericht verwijderd.

Authenticatie in APNS: Token en Certificaat

Apple ondersteunt twee methoden voor authenticatie van de applicatieserver bij het verzenden van pushmeldingen. Elke methode heeft zijn eigen kenmerken wat betreft geldigheidsduur, beheer en gebruiksgemak.

Token-based authenticatie — de door Apple aanbevolen methode sinds 2019. U maakt één p8-sleutel aan in Apple Developer Console, laadt deze op de server en ondertekent elk APNS-verzoek ermee. De sleutel verloopt niet en werkt voor alle apps van uw account.

Welke authenticatiemethode te kiezen

Voor nieuwe projecten heeft Token-based authenticatie de duidelijke voorkeur: één p8-sleutel voor het hele account, onbeperkt, zonder afhankelijkheid van de omgeving. Certificate-based (.p12) wordt nog steeds gebruikt in legacy-projecten, maar vereist jaarlijkse vervanging en aparte certificaten voor Sandbox en Production. Houd rekening met de vervaldatum van het certificaat bij het plannen van CI/CD.

Typen APNS-pushmeldingen

APNS ondersteunt drie typen pushmeldingen die verschillen in gedrag op het apparaat en vereisten voor verzoekattributen. De keuze van het type hangt af van het UX-scenario en de urgentie van het bericht.

• Alert — standaardmelding met titel, tekst en optionele actieknoppen
• Background — stille bezorging van gegevens (silent push) zonder weergave aan de gebruiker, verwerkt in application:didReceiveRemoteNotification
• VOIP — speciaal type voor VoIP-apps (PushKit), wordt onmiddellijk bezorgd, zelfs als de app is gesloten

Voor Background-meldingen moet u de sleutel content-available: 1 opgeven en de prioriteit instellen op 5 (energiezuinige bezorging). Het systeem kan het aantal achtergrondmeldingen beperken als de app ze niet tijdig verwerkt.

Configuratie van bezorgingsprioriteit

APNS ondersteunt twee prioriteitswaarden: 10 (directe bezorging) en 5 (energiezuinig). Gebruik voor alert-meldingen 10 — de gebruiker moet ze onmiddellijk ontvangen. Gebruik voor background 5 — het systeem kan de bezorging vertragen om de batterij te sparen. Een onjuiste prioriteit voor background kan leiden tot afwijzing van de melding door APNS.

Formaat van APNS-payload

APNS accepteert payload in JSON-formaat met een maximale grootte van 4 KB voor gewone meldingen en 5 KB voor VOIP. De payload bevat de verplichte aps-woordenlijst met weergave-instellingen en optionele aangepaste velden.

{
    "aps": {
        "alert": {
            "title": "Nieuw bericht",
            "body": "Je hebt 3 ongelezen chats"
        },
        "badge": 3,
        "sound": "default",
        "category": "message_category",
        "thread-id": "chat_room_42"
    },
    "customData": {
        "chatId": "42"
    }
}

De sleutel thread-id groepeert meldingen in het iOS-meldingscentrum. De sleutel category koppelt de melding aan UNNotificationCategory voor het tonen van actieknoppen. Zonder deze sleutels worden alle meldingen afzonderlijk weergegeven.

Aangepaste velden in APNS-payload

Naast de verplichte aps-woordenlijst kan de APNS-payload aangepaste velden op het hoogste niveau bevatten. Deze velden zijn toegankelijk voor de app via de userInfo-woordenlijst bij het verwerken van de melding. Aangepaste gegevens zijn handig voor het doorgeven van entiteits-ID’s, schermen of links. De maximale payloadgrootte is 4 KB, dus vermijd het verzenden van grote hoeveelheden gegevens via push; laad ze via API na het openen van de melding.

Voorbeeld van verzenden via HTTP/2 API

Om een pushmelding te verzenden, moet de server een POST-verzoek naar het APNS-endpoint sturen met de juiste authenticatieheaders. Hieronder staat een voorbeeld in Node.js met Token-based authenticatie.

const http2 = require("http2")
const fs = require("fs")
const jwt = require("jsonwebtoken")

const token = jwt.sign(
    { iss: "TEAM_ID", iat: Math.floor(Date.now() / 1000) },
    fs.readFileSync("AuthKey.p8"),
    { algorithm: "ES256", keyid: "KEY_ID" }
)

const payload = JSON.stringify({
    aps: { alert: { title: "Hallo!", body: "Test push" } }
})

const client = http2.connect(
    "https://api.push.apple.com"
)

const req = client.request({
    ":method": "POST",
    ":path": "/3/device/DEVICE_PUSH_TOKEN",
    "authorization": "bearer " + token,
    "apns-push-type": "alert",
    "apns-topic": "com.example.app",
    "apns-priority": "10"
})
req.end(payload)

req.on("response", (headers) => {
    if (headers[":status"] === 200) {
        console.log("Push succesvol verzonden")
    }
})

Na het verzenden retourneert APNS HTTP-status 200 bij succesvolle bezorging of een foutcode met beschrijving in de antwoordbody. Het is belangrijk om de fout token-unregistered (410) af te handelen — een dergelijke token moet van de server worden verwijderd, omdat de app van het apparaat is verwijderd.

APNS-fouten en hun afhandeling

APNS retourneert HTTP-statussen voor elk verzendverzoek. Succesvol verzenden — status 200. Fouten vereisen verschillende afhandelingsstrategieën. BadDeviceToken (400) of Unregistered (410) — de apparaattoken is verlopen, moet van de server worden verwijderd. PayloadTooLarge (413) — de limiet van 4 KB is overschreden, verkort de payload.

Fout TooManyRequests (429) — de limiet van verzoeken is overschreden. APNS stelt een quotum in voor het aantal verzendingen per seconde. Bij ontvangst van 429 moet u een exponentiële vertraging (exponential backoff) implementeren en het verzenden opnieuw proberen. Het wordt aanbevolen om niet meer dan 100 verzoeken per seconde per HTTP/2-verbinding te doen.

Fouten aan APNS-zijde — 500 en 503 (Internal Server Error / Service Unavailable). Dit zijn tijdelijke storingen van de Apple-infrastructuur. Herhaal in dergelijke gevallen het verzenden met een vertraging van 1–5 seconden, maximaal 3 pogingen. Constante 5xx-fouten op een volledig werkende server komen zelden voor en houden meestal verband met TLS-verbindingsproblemen.

Voor de Production-omgeving moet u logboekregistratie van alle APNS-fouten implementeren met vermelding van de token, foutcode en tijd. Dit helpt om problemen met certificaten, quota’s of specifieke apparaattokens snel te identificeren. Controleer regelmatig de geldigheidsduur van certificaten als u Certificate-based authenticatie gebruikt.