APNS: Was es ist, wie Apple Push Notification Service funktioniert und seine Architektur

Was ist APNS?

Apple Push Notification Service (APNS) ist Apples proprietärer Dienst zum Routing von Push-Benachrichtigungen vom Anwendungsserver zu Benutzergeräten. Im Gegensatz zu FCM unterstützt APNS weder Android noch andere Plattformen — es ist vollständig an das Apple-Ökosystem gebunden.

Der Dienst arbeitet über eine permanente TLS-Verbindung, die jedes Apple-Gerät beim Start mit APNS-Servern aufbaut. Diese Verbindung wird im Hintergrund aufrechterhalten und zur Zustellung von Benachrichtigungen mit minimaler Latenz verwendet.

APNS übernimmt die gesamte Zustellungsinfrastruktur: Verschlüsselung, Authentifizierung, Prioritätensetzung und erneute Übertragung, wenn das Gerät nicht verfügbar ist. Der Entwickler muss nur eine korrekt formatierte Payload und ein gültiges Push-Token bereitstellen.

Entwicklung von APNS

Ursprünglich arbeitete APNS über ein binäres Protokoll auf den Ports 2195–2196. Seit 2015 hat Apple den Dienst auf das moderne HTTP/2-Protokoll umgestellt, das Multiplexing, Header-Kompression und Server-Push-Benachrichtigungen unterstützt. HTTP/2 wurde im Juni 2020 verpflichtend.

Wie funktioniert Apple Push Notification Service?

Der Prozess der Push-Benachrichtigungszustellung über APNS besteht aus fünf Phasen: Geräteregistrierung, Erhalt eines Push-Tokens, Senden der Anfrage durch den Server, APNS-Routing und Zustellung an das Gerät.

• Registrierung — beim Start ruft die App registerForRemoteNotifications auf, das System kontaktiert APNS
• Token — APNS gibt ein Push-Token an das Gerät zurück — eine eindeutige Zeichenfolge, die die App auf dem Gerät identifiziert
• Senden — der Anwendungsserver sendet eine POST-Anfrage an https://api.push.apple.com mit Token und Payload
• Routing — APNS findet das Gerät anhand des Tokens und liefert die Nachricht über die TLS-Verbindung
• Verarbeitung — iOS/macOS zeigt die Benachrichtigung an oder leitet sie je nach Zustand an die App weiter

Wenn das Gerät nicht verfügbar ist (ausgeschaltet oder kein Netzwerk), speichert APNS die letzte Nachricht für jede App und liefert sie bei Wiederherstellung der Verbindung aus. Die maximale Speicherdauer beträgt 4 Wochen, danach wird die Nachricht gelöscht.

APNS-Authentifizierung: Token und Zertifikat

Apple unterstützt zwei Methoden zur Authentifizierung des Anwendungsservers beim Senden von Push-Benachrichtigungen. Jede Methode hat ihre eigenen Eigenschaften hinsichtlich Gültigkeitsdauer, Verwaltung und Benutzerfreundlichkeit.

Die Token-basierte Authentifizierung ist die von Apple seit 2019 empfohlene Methode. Sie erstellen einen einzelnen p8-Schlüssel in der Apple Developer Console, laden ihn auf Ihren Server hoch und signieren jede APNS-Anfrage damit. Der Schlüssel läuft nie ab und funktioniert für alle Apps Ihres Kontos.

Welche Authentifizierungsmethode wählen

Für neue Projekte ist die Token-basierte Authentifizierung eindeutig vorzuziehen: ein p8-Schlüssel für das gesamte Konto, unbegrenzt, ohne Umgebungsbindung. Die Zertifikat-basierte (.p12) wird weiterhin in Legacy-Projekten verwendet, erfordert jedoch einen jährlichen Austausch und separate Zertifikate für Sandbox und Production. Berücksichtigen Sie den Zertifikatsablauf bei der Planung von CI/CD.

Arten von APNS-Push-Benachrichtigungen

APNS unterstützt drei Arten von Push-Benachrichtigungen, die sich im Verhalten auf dem Gerät und in den Anforderungsattributen unterscheiden. Die Wahl des Typs hängt vom UX-Szenario und der Dringlichkeit der Nachricht ab.

• Alert — Standardbenachrichtigung mit Titel, Text und optionalen Aktionsschaltflächen
• Background — stille Datenzustellung (Silent Push) ohne Anzeige für den Benutzer, verarbeitet in application:didReceiveRemoteNotification
• VOIP — spezieller Typ für VoIP-Apps (PushKit), sofortige Zustellung auch bei geschlossener App

Für Background-Benachrichtigungen müssen Sie den Schlüssel content-available: 1 angeben und die Priorität auf 5 (energieeffiziente Zustellung) setzen. Das System kann die Anzahl der Hintergrundbenachrichtigungen begrenzen, wenn die App sie nicht rechtzeitig verarbeitet.

Konfiguration der Zustellungspriorität

APNS unterstützt zwei Prioritätswerte: 10 (sofortige Zustellung) und 5 (energieeffizient). Verwenden Sie für Alert-Benachrichtigungen 10 — der Benutzer sollte sie sofort erhalten. Für Background-Benachrichtigungen verwenden Sie 5 — das System kann die Zustellung verzögern, um Batterie zu sparen. Eine falsche Priorität für Background kann zur Ablehnung durch APNS führen.

APNS-Payload-Format

APNS akzeptiert Payload im JSON-Format mit einer maximalen Größe von 4 KB für reguläre Benachrichtigungen und 5 KB für VOIP. Die Payload enthält das obligatorische aps-Wörterbuch mit Anzeigeeinstellungen und optionale benutzerdefinierte Felder.

{
    "aps": {
        "alert": {
            "title": "Neue Nachricht",
            "body": "Sie haben 3 ungelesene Chats"
        },
        "badge": 3,
        "sound": "default",
        "category": "message_category",
        "thread-id": "chat_room_42"
    },
    "customData": {
        "chatId": "42"
    }
}

Der Schlüssel thread-id gruppiert Benachrichtigungen im iOS-Benachrichtigungscenter. Der Schlüssel category verknüpft die Benachrichtigung mit einer UNNotificationCategory zur Anzeige von Aktionsschaltflächen. Ohne diese Schlüssel werden alle Benachrichtigungen einzeln angezeigt.

Benutzerdefinierte Felder in APNS-Payload

Zusätzlich zum obligatorischen aps-Wörterbuch kann die APNS-Payload beliebige benutzerdefinierte Felder auf oberster Ebene enthalten. Diese Felder sind für die App über das userInfo-Wörterbuch bei der Verarbeitung der Benachrichtigung zugänglich. Benutzerdefinierte Daten eignen sich zum Übergeben von Entitätskennungen, Bildschirmen oder Links. Die maximale Payload-Größe beträgt 4 KB, daher vermeiden Sie die Übertragung großer Datenmengen per Push; laden Sie sie nach dem Öffnen der Benachrichtigung über API.

Beispiel für den Versand über HTTP/2-API

Um eine Push-Benachrichtigung vom Server zu senden, müssen Sie eine POST-Anfrage an den APNS-Endpunkt mit korrekten Authentifizierungsheadern ausführen. Nachfolgend ein Beispiel in Node.js unter Verwendung der Token-basierten Authentifizierung.

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

Nach dem Senden gibt APNS bei erfolgreicher Zustellung den HTTP-Status 200 oder einen Fehlercode mit Beschreibung im Antworttext zurück. Es ist wichtig, token-unregistered-Fehler (410) zu behandeln — solche Tokens sollten vom Server entfernt werden, da die App vom Gerät gelöscht wurde.

APNS-Fehler und ihre Behandlung

APNS gibt für jede Sendeanforderung HTTP-Statuscodes zurück. Erfolgreiche Zustellung gibt Status 200 zurück. Fehler erfordern unterschiedliche Behandlungsstrategien. BadDeviceToken (400) oder Unregistered (410) — das Geräte-Token ist veraltet und sollte vom Server entfernt werden. PayloadTooLarge (413) — das 4-KB-Limit wurde überschritten, reduzieren Sie die Payload.

TooManyRequests (429) — Anforderungslimit überschritten. APNS legt ein Kontingent für die Anzahl der Sendungen pro Sekunde fest. Bei Erhalt von 429 implementieren Sie einen exponentiellen Backoff und wiederholen Sie den Sendevorgang. Es wird empfohlen, 100 Anfragen pro Sekunde pro HTTP/2-Verbindung nicht zu überschreiten.

APNS-seitige Fehler — 500 und 503 (Interner Serverfehler / Dienst nicht verfügbar). Dies sind vorübergehende Ausfälle der Apple-Infrastruktur. Wiederholen Sie in solchen Fällen den Sendevorgang mit einer Verzögerung von 1–5 Sekunden, maximal 3 Versuche. Anhaltende 5xx-Fehler bei voll funktionsfähigem Server sind selten und hängen normalerweise mit TLS-Verbindungsproblemen zusammen.

Für Produktionsumgebungen implementieren Sie unbedingt die Protokollierung aller APNS-Fehler mit Token, Fehlercode und Zeitpunkt. Dies hilft, Probleme mit Zertifikaten, Kontingenten oder bestimmten Geräte-Tokens schnell zu identifizieren. Überprüfen Sie regelmäßig die Ablaufdaten von Zertifikaten, wenn Sie die zertifikatbasierte Authentifizierung verwenden.