Device Token: hoe het werkt, APNS-token verkrijgen en bijwerken

Wat is Device Token

Device Token (apparaattoken) is een unieke identificatie in de vorm van een hex-string die APNS (Apple Push Notification Service) genereert voor elke app op een iOS-apparaat. De token is de sleutel waarmee de server pushmeldingen naar een specifiek apparaat stuurt. Zonder een correcte Device Token kan de server geen pushmelding leveren — APNS wijst het verzoek af met fout 400 BadRequest.

Hoe de token wordt gevormd

Device Token wordt gemaakt door het iOS-systeem bij het eerste contact van de app met APNS na installatie. Het generatieproces omvat een cryptografische koppeling aan de app-identificatie (bundle ID) en de unieke apparaatidentificatie (UID), waarna APNS een 32-byte token in hex-formaat (64 tekens) aan de app retourneert. De token is niet permanent — het systeem kan onder bepaalde omstandigheden een nieuwe genereren.

Rol van de token bij levering van pushmeldingen

Wanneer de server een pushmelding verzendt, voegt hij Device Token toe aan het HTTP/2-verzoek aan APNS. APNS controleert de geldigheid van de token: als de token tot een andere omgeving behoort (sandbox in plaats van production), is verlopen of is ingetrokken, retourneert de Apple-server fout 410 Gone of 400 BadRequest. Pas na succesvolle validatie van de token begint APNS met de levering van de melding aan het apparaat.

Verschil tussen Device Token en andere identificaties

Device Token moet niet worden verward met IDFA (Identifier for Advertisers), IDFV (Identifier for Vendor) of UID (Unique Device Identifier). IDFA en IDFV worden gebruikt voor reclame en analyses, UID is het hardware-serienummer. Device Token bestaat uitsluitend voor pushmeldingen en geeft geen informatie over de gebruiker of het apparaat buiten APNS prijs.

Hoe het apparaat de token ontvangt en registreert

Het proces van het verkrijgen van Device Token bestaat uit verschillende verplichte stappen, beginnend met het aanvragen van toestemming van de gebruiker en eindigend met het verzenden van de token naar de server. Elke stap is cruciaal — het overslaan ervan leidt tot onmogelijkheid om pushmeldingen naar het apparaat te sturen.

Toestemming voor meldingen aanvragen

Eerste stap: de app vraagt de gebruiker om toestemming voor het verzenden van meldingen via UNUserNotificationCenter.current().requestAuthorization. De gebruiker kan akkoord gaan, weigeren of optionele opties kiezen (alert, badge, sound). Zonder expliciete toestemming van de gebruiker geeft het systeem geen Device Token af, zelfs niet als de app registerForRemoteNotifications aanroept. Na het verkrijgen van toestemming roept de app UIApplication.shared.registerForRemoteNotifications() aan, wat het registratieproces in APNS start.

Ontvangen van de token van APNS

Na registratie retourneert APNS de token via de AppDelegate-delegate: application(_:didRegisterForRemoteNotificationsWithDeviceToken:). Succesvolle aanroep bevat een Data-object met de token, die moet worden geconverteerd naar een hex-string voor verzending naar de server. Bij een fout roept het systeem application(_:didFailToRegisterForRemoteNotificationsWithError:) aan met een beschrijving van het probleem: onjuiste certificaatconfiguratie, geen netwerk of onjuiste projectconfiguratie.

Token naar uw eigen server verzenden

Na het ontvangen van de token moet de app deze onmiddellijk naar de eigen server sturen voor opslag in de database. Het API-verzoek omvat de token, apparaatidentificatie (voor koppeling), omgeving (sandbox/production) en optioneel extra gegevens: OS-versie, apparaatmodel, taal. Het wordt aanbevolen om het verzenden van de token bij elke app-start te herhalen, zodat de server altijd een actuele token heeft.

// Toestemming aanvragen en registreren in APNS
func registerForPushNotifications() {
    UNUserNotificationCenter.current()
        .requestAuthorization(options: [.alert, .sound, .badge]) {
        [weak self] granted, error in
        guard granted else {
            print("Geen toestemming verkregen")
            return
        }
        DispatchQueue.main.async {
            UIApplication.shared
                .registerForRemoteNotifications()
        }
    }
}

// Device Token ontvangen van APNS
func application(
    _ application: UIApplication,
    didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data
) {
    let tokenString = deviceToken
        .map { String(format: "%02.2hhx", $0) }
        .joined()
    print("Device Token: \(tokenString)")

    // Token naar server sturen
    PushTokenService.shared
        .sendTokenToServer(tokenString) { success in
        if success {
            UserDefaults.standard.set(tokenString,
                forKey: "lastDeviceToken")
        }
    }
}

Tokenbeheer aan de serverzijde

Het servergedeelte van het push-systeem moet Device Token in de database opslaan, gekoppeld aan de gebruiker en omgeving. Bij het verzenden van een melding vormt de server een verzoek aan APNS, met de token in de URL en een JWT-token (of certificaat) voor autorisatie. Correct tokenbeheer heeft een kritieke invloed op het leveringspercentage van pushmeldingen.

Databasestructuur voor tokens

De tokentabel op de server moet ten minste bevatten: Device Token (uniek), gebruikersidentificatie, omgeving (sandbox/production), datum laatste update en status (actief/inactief). Aanbevolen wordt een index op token toe te voegen voor snel zoeken bij verzending en op gebruiker voor het verkrijgen van de lijst van alle apparaten van de gebruiker. Veel apps staan een gebruiker toe meerdere apparaten te hebben — elk met zijn eigen token.

Autorisatie van verzoeken aan APNS

Voor het verzenden van een pushmelding moet de server het verzoek aan APNS op twee manieren autoriseren. Certificaatsgebaseerd (Certificate-based) gebruikt een SSL-certificaat gegenereerd in de Apple Developer Console. Token-gebaseerde methode gebruikt JWT met een .p8-sleutel, die tot 30 dagen geldig is zonder dat het certificaat hoeft te worden vernieuwd. Token-gebaseerde autorisatie wordt als moderner beschouwd en wordt door Apple aanbevolen voor nieuwe projecten.

Vorming van HTTP/2 APNS-verzoek

Het verzoek aan APNS omvat de HTTP/2 POST-methode, URL met pad /3/device/{device_token}, autorisatie-headers en JSON-body met payload. De apns-topic-header bevat verplicht de bundle ID van de app. apns-priority specificeert de leveringsprioriteit (5 — onmiddellijk, 10 — batterijbesparing). apns-expiration stelt de tijd in seconden vanaf epoch in waarbinnen APNS zal proberen de melding te leveren.

// Voorbeeld van push-verzending in Node.js via APNS HTTP/2
const http2 = require('http2');
const client = http2.connect('https://api.push.apple.com');

const deviceToken = 'abcdef0123456789...';
const payload = JSON.stringify({
    "aps": { "alert": "Hello!", "sound": "default" }
});

const req = client.request({
    ':method': 'POST',
    ':path': `/3/device/${deviceToken}`,
    'apns-topic': 'com.example.app',
    'apns-priority': '10',
    'apns-expiration': '0',
    'authorization': `bearer ${jwtToken}`
});
req.write(payload);
req.end();
req.on('response', (headers) => {
    if (headers[':status'] === '200') {
        console.log('Push sent successfully');
    }
});

Batchverzending en snelheidsbeperking

Bij het verzenden van pushmeldingen naar een groot aantal apparaten gebruikt u batchverzending met snelheidscontrole. APNS raadt aan niet meer dan 1500 verzoeken per seconde per verbinding te overschrijden. Bij overschrijding van de limiet retourneert de Apple-server fout 429 Too Many Requests. Voor grootschalige verzending gebruikt u meerdere verbindingen en verdeelt u de belasting gelijkmatig over de apparaten.

Bijwerken en ongeldig maken van tokens

Device Token is niet permanent en kan in verschillende scenario’s veranderen, wat een updatemechanisme op de server vereist. Als de server push blijft sturen naar een verouderde token, retourneert APNS fout 410 Gone, wat aangeeft dat de token niet langer geldig is voor die omgeving.

Wanneer verandert de token

Apple documenteert verschillende scenario’s waarin Device Token verandert: de gebruiker installeert de app opnieuw, herstelt het apparaat vanuit iCloud-backup, installeert een nieuwe iOS-versie, en bij resetten van netwerk- of privacy-instellingen. In elk geval ontvangt de app bij de volgende start een nieuwe token van APNS. De server moet de token in de database bijwerken, de oude verwijderen en de nieuwe opslaan.

Afhandeling van fout 410 Gone van APNS

Wanneer de server push naar een verouderde token stuurt, retourneert APNS HTTP 410 met de header apns-unless-timestamp. Deze header geeft het tijdstip aan waarop de token ongeldig is geworden. De server moet deze token onmiddellijk uit de database verwijderen of deactiveren om er niet opnieuw naar te sturen. Het negeren van fout 410 leidt tot verspilling van middelen en verlaging van de leveringsratio.

Periodieke opschoning van inactieve tokens

Om de tokendatabase actueel te houden, wordt periodieke opschoning aanbevolen. Het opschoonscript analyseert APNS-logboeken van de laatste N dagen, vindt alle tokens waarvoor fout 410 is ontvangen en deactiveert ze in de database. Daarnaast kunnen tokens worden verwijderd waarop langer dan 90 dagen geen gebruikersactiviteit is geweest — dit zijn nutteloze records die alleen de databasegrootte vergroten.

Controle van tokens vóór massaverzending

Vóór massaverzending van pushmeldingen (nieuwsbrief, promotiecampagne) wordt aanbevolen de actualiteit van tokens vooraf te controleren. APNS biedt geen directe API voor batchvalidatie van tokens, daarom wordt de strategie gebruikt van het verzenden van een test-push met lage prioriteit en analyse van fouten. Tokens die fout 410 hebben geretourneerd, worden uitgesloten van de hoofdzending.

Voorbeeldcode voor het verkrijgen van Device Token

Laten we de volledige cyclus van het verkrijgen van Device Token in Swift bekijken, inclusief foutafhandeling en verzending naar de server. De code omvat toestemming aanvragen, registratie in APNS, conversie van Data naar hex-string, foutafhandeling en verzending van de token naar de eigen server met herhaalde pogingen bij mislukking.

import UIKit
import UserNotifications

final class PushNotificationManager: NSObject {

    static let shared = PushNotificationManager()
    private let apiClient = APIClient()
    private var currentToken: String?

    func register() {
        UNUserNotificationCenter.current()
            .requestAuthorization(
                options: [.alert, .badge, .sound]) {
            [weak self] granted, error in
            guard granted else {
                Analytics.log(
                    "Push permission denied")
                return
            }
            DispatchQueue.main.async {
                UIApplication.shared
                    .registerForRemoteNotifications()
            }
        }
    }

    func handleDeviceToken(_ tokenData: Data) {
        let token = tokenData
            .map { String(format: "%02.2hhx", $0) }
            .joined()

        guard token != currentToken else { return }
        currentToken = token
        sendTokenToServer(token)
    }

    func handleRegistrationError(_ error: Error) {
        Analytics.log(
            "Push registration failed: \(error)")

        // Opnieuw proberen na vertraging bij netwerkfouten
        if let urlError = error as? URLError,
            urlError.code == .notConnectedToInternet {
            DispatchQueue.main.asyncAfter(
                deadline: .now() + 10) { [weak self] in
                self?.register()
            }
        }
    }

    private func sendTokenToServer(_ token: String) {
        let body = PushTokenRequest(
            token: token,
            environment: Environment.current == .debug
                ? "sandbox" : "production",
            osVersion: UIDevice.current.systemVersion,
            locale: Locale.current.identifier
        )
        apiClient.sendToken(body) { [weak self] result in
            if case .success = result {
                self?.currentToken = token
            }
        }
    }
}

Foutafhandeling bij registratie

Fouten bij registratie in APNS kunnen door verschillende oorzaken worden veroorzaakt. De meest voorkomende — geen netwerk, onjuiste certificaatconfiguratie in Xcode (bijv. de capability Push Notifications uitgeschakeld), gebruik van de simulator (die geen push ondersteunt) of een onjuist provisioning profile. In productie is het belangrijk om fouten te loggen en, indien mogelijk, de registratie bij de volgende app-start te herhalen.

Device Token testen op de simulator

De iOS Simulator ondersteunt het verkrijgen van een echte Device Token niet. Voor het testen van registratie op de simulator gebruikt u i386-architectuurcontroles: in de debug-build kunt u het verkrijgen van de token simuleren of UI-tests met mock-objecten gebruiken. Echt testen van pushmeldingen wordt altijd uitgevoerd op een fysiek apparaat dat is verbonden met Xcode.