Device Token: hur APNS-token fungerar, hämta och uppdatera

Vad är Device Token

Device Token (enhetstoken) är en unik identifierare i form av en hex-sträng som APNS (Apple Push Notification Service) genererar för varje app på en iOS-enhet. Token är nyckeln som servern använder för att skicka push-notiser till en specifik enhet. Utan en korrekt Device Token kan servern inte leverera push — APNS avvisar begäran med fel 400 BadRequest.

Hur token skapas

Device Token skapas av iOS-systemet när appen för första gången kontaktar APNS efter installation. Genereringsprocessen innefattar kryptografisk bindning till appens identifierare (bundle ID) och enhetens unika identifierare (UID), varefter APNS returnerar en 32-byte token i hex-format (64 tecken). Token är inte permanent — systemet kan generera en ny under vissa förhållanden.

Tokenens roll vid leverans av push-notiser

När servern skickar en push-notis inkluderar den Device Token i HTTP/2-begäran till APNS. APNS validerar token: om token tillhör en annan miljö (sandbox istället för production), har löpt ut eller är återkallad, returnerar Apple-servern fel 410 Gone eller 400 BadRequest. Först efter framgångsrik validering börjar APNS leverera notisen till enheten.

Skillnad mellan Device Token och andra identifierare

Device Token ska inte förväxlas med IDFA (Identifier for Advertisers), IDFV (Identifier for Vendor) eller UID (Unique Device Identifier). IDFA och IDFV används för reklam och analys, UID är enhetens serienummer. Device Token existerar enbart för push-notiser och avslöjar ingen information om användaren eller enheten utanför APNS.

Hur enheten får och registrerar token

Processen för att hämta Device Token består av flera nödvändiga steg, från att begära tillstånd från användaren till att skicka token till servern. Varje steg är kritiskt — om något steg hoppas över kan push-notiser inte skickas till enheten.

Begär tillstånd för notiser

Första steget är att appen begär tillstånd från användaren att skicka notiser via UNUserNotificationCenter.current().requestAuthorization. Användaren kan godkänna, neka eller välja valfria alternativ (alert, badge, sound). Utan uttryckligt godkännande från användaren kommer systemet inte att utfärda Device Token, även om appen anropar registerForRemoteNotifications. Efter godkännande anropar appen UIApplication.shared.registerForRemoteNotifications(), vilket initierar registreringsprocessen i APNS.

Hämta token från APNS

Efter registrering returnerar APNS token via AppDelegate-delegaten: application(_:didRegisterForRemoteNotificationsWithDeviceToken:). Ett lyckat anrop innehåller ett Data-objekt med token som måste konverteras till en hex-sträng för att skickas till servern. Vid fel anropar systemet application(_:didFailToRegisterForRemoteNotificationsWithError:) med en beskrivning av problemet: felaktig certifikatkonfiguration, nätverksproblem eller felaktig projektkonfiguration.

Skicka token till din server

Efter att ha fått token måste appen omedelbart skicka den till sin server för lagring i databasen. API-begäran inkluderar token, enhetsidentifierare (för matchning), miljö (sandbox/production) och eventuellt ytterligare data: OS-version, enhetsmodell, språk. Det rekommenderas att skicka token vid varje appstart så att servern alltid har den senaste token.

// Begär tillstånd och registrera i APNS
func registerForPushNotifications() {
    UNUserNotificationCenter.current()
        .requestAuthorization(options: [.alert, .sound, .badge]) {
        [weak self] granted, error in
        guard granted else {
            print("Tillstånd ej beviljat")
            return
        }
        DispatchQueue.main.async {
            UIApplication.shared
                .registerForRemoteNotifications()
        }
    }
}

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

    // Skicka token till servern
    PushTokenService.shared
        .sendTokenToServer(tokenString) { success in
        if success {
            UserDefaults.standard.set(tokenString,
                forKey: "lastDeviceToken")
        }
    }
}

Hantera tokens på serversidan

Serverdelen av push-systemet måste lagra Device Token i databasen, kopplad till användaren och miljön. När en notis skickas bygger servern en begäran till APNS med token i URL:en och en JWT-token (eller certifikat) för autentisering. Korrekt tokenhantering har stor inverkan på leveransgraden för push-notiser.

Databasstruktur för tokens

Tokentabellen på servern bör minst innehålla: Device Token (unik), användaridentifierare, miljö (sandbox/production), senaste uppdateringsdatum och status (aktiv/inaktiv). Det rekommenderas att lägga till index på token för snabb sökning vid sändning och på användare för att hämta listan över alla användarens enheter. Många appar tillåter en användare att ha flera enheter — varje enhet har sin egen token.

Autentisering av APNS-begäran

För att skicka en push-notis måste servern autentisera begäran till APNS på två sätt. Certifikatbaserad använder ett SSL-certifikat som genererats i Apple Developer Console. Tokenbaserad använder JWT (JSON Web Token) med en .p8-nyckel som är giltig i upp till 30 dagar utan att certifikatet behöver förnyas. Tokenbaserad autentisering anses vara mer modern och rekommenderas av Apple för nya projekt.

Skapa APNS HTTP/2-begäran

Begäran till APNS innefattar HTTP/2-metoden POST, URL med sökvägen /3/device/{device_token}, autentiseringshuvuden och JSON-kropp med payload. Huvudet apns-topic måste innehålla appens bundle ID. apns-priority anger leveransprioritet (5 — omedelbart, 10 — batteribesparande). apns-expiration anger tiden i sekunder sedan epoch inom vilken APNS ska försöka leverera notisen.

// Exempel på push-sändning med 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('svar', (headers) => {
    if (headers[':status'] === '200') {
        console.log('Push skickades framgångsrikt');
    }
});

Batchutskick och begränsning

När du skickar push-notiser till ett stort antal enheter, använd batchutskick med hastighetskontroll. APNS rekommenderar att inte överskrida 1500 begäran per sekund per anslutning. Om gränsen överskrids returnerar Apple-servern fel 429 Too Many Requests. För storskaliga utskick, använd flera anslutningar och fördela belastningen jämnt över enheterna.

Uppdatering och ogiltigförklaring av tokens

Device Token är inte permanent och kan ändras i flera scenarier, vilket kräver en uppdateringsmekanism på servern. Om servern fortsätter att skicka push till en föråldrad token returnerar APNS fel 410 Gone, vilket indikerar att token inte längre är giltig för den aktuella miljön.

När token ändras

Apple dokumenterar flera scenarier där Device Token ändras: användaren ominstallerar appen, återställer enheten från iCloud-säkerhetskopia, installerar en ny iOS-version, samt vid återställning av nätverks- eller integritetsinställningar. I varje fall får appen en ny token från APNS vid nästa start. Servern bör uppdatera token i databasen genom att ta bort den gamla och spara den nya.

Hantera fel 410 Gone från APNS

När servern skickar push till en föråldrad token returnerar APNS HTTP 410 med huvudet apns-unless-timestamp. Detta huvud anger tiden efter vilken token blev ogiltig. Servern bör omedelbart ta bort eller inaktivera denna token i databasen för att undvika upprepade utskick. Att ignorera fel 410 leder till resursslöseri och lägre leveransgrad.

Periodisk rensning av inaktiva tokens

För att hålla tokendatabasen aktuell rekommenderas periodisk rensning. Rensningsskriptet analyserar APNS-loggar från de senaste N dagarna, hittar alla tokens som returnerat fel 410 och inaktiverar dem i databasen. Dessutom kan tokens utan användaraktivitet på mer än 90 dagar tas bort — dessa är onödiga poster som bara ökar databasens storlek.

Validera tokens före massutskick

Före massutskick av push-notiser (nyhetsbrev, kampanjer) rekommenderas att förvalidera tokens. APNS tillhandahåller inget direkt API för batchvalidering av tokens, så strategin är att skicka ett test-push med låg prioritet och analysera fel. Tokens som returnerar fel 410 exkluderas från huvudutskicket.

Kodexempel för att hämta Device Token

Låt oss gå igenom hela cykeln för att hämta Device Token i Swift, inklusive felhantering och överföring till servern. Koden täcker tillståndsbegäran, APNS-registrering, konvertering av Data till hex-sträng, felhantering och sändning av token till din server med återförsök vid misslyckande.

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

        // Försök igen efter fördröjning vid nätverksfel
        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
            }
        }
    }
}

Felhantering vid registrering

Fel vid APNS-registrering kan orsakas av olika anledningar. De vanligaste är: nätverksproblem, felaktig certifikatkonfiguration i Xcode (t.ex. Push Notifications-funktionen avaktiverad), användning av simulator (som inte stöder push) eller felaktig provisioning profile. I produktion är det viktigt att logga fel och, om möjligt, försöka registrera igen vid nästa appstart.

Testa Device Token i simulatorn

iOS Simulator stöder inte att hämta en riktig Device Token. För att testa registrering i simulatorn, använd i386-arkitekturkontroller: i en debug-build kan du simulera tokenhämtning eller använda UI-tester med mock-objekt. Verklig testning av push-notiser utförs alltid på en fysisk enhet ansluten till Xcode.