Was sind Push-Benachrichtigungen (APNs und FCM)?

Eine Push-Benachrichtigung ist eine vom Server ausgelöste Nachricht, die die Push-Dienste der Plattform an ein Gerät zustellen, auch bei geschlossener App. Produktteams kennen Push als Kanal zur Nutzerbindung; dieser Eintrag behandelt die Zustellmaschinerie – denn die Maschinerie erklärt jede Eigenart, über die Produktteams klagen. Die zentrale Tatsache: Ihr Server spricht nie mit dem Telefon. Jedes mobile Betriebssystem unterhält genau eine batterieoptimierte, dauerhafte Verbindung zum Push-Gateway seines Herstellers – APNs (Apple Push Notification service) für Apple-Geräte, FCM für Android – und jede Benachrichtigung jeder App läuft durch diese geteilte Leitung.

Das Wichtigste in Kürze

Die Zustellkette von Anfang bis Ende

1  App bittet das OS, sich für Push zu registrieren
2  Push-Dienst der Plattform gibt ein DEVICE TOKEN aus (die Adresse)
3  App sendet das Token an IHR Backend, das es speichert
4  Ereignis tritt ein → Backend sendet { token, payload ≤4 KB } an APNs/FCM
5  Push-Dienst findet die dauerhafte Verbindung des Geräts → stellt zu
6  OS zeigt die Benachrichtigung — oder weckt die App für stillen Push

Die zweite Aufgabe von FCM: mit hinterlegten APNs-Zugangsdaten nimmt er
eine Anfrage entgegen und stellt für Apple-Geräte APNs-konform neu aus —
eine API-Oberfläche für beide Plattformen. Ein BaaS nimmt selbst das ab.

Beide Hälften im Code – der Client registriert seine Adresse, das Backend sendet an einen Kanal:

// JavaScript — Cloud Code (cloud/main.js)
// One send call reaches both platform push services
await Parse.Push.send({
  channels: ['scores'], // or `where:` with an Installation query
  data: {
    alert: 'Kickoff! Follow the match live.',
    badge: 'Increment',
    uri: 'app://match/8fk2',
  },
}, { useMasterKey: true });
// Back4app routes to APNs for Apple devices and FCM for Android — one API

// Flutter / Dart — Back4app Flutter SDK
// Register this install for push: token + channels live in an Installation
final installation = await ParseInstallation.currentInstallation();
installation
  ..set('channels', ['scores']) // subscribe to a topic-like channel
  ..set('user', currentUser);   // enables targeting by user later
await installation.save();
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching APNs or FCM directly.

// iOS / Swift — Back4app Swift SDK
// Register this install for push: token + channels live in an Installation
var installation = ParseInstallation.current
installation?.channels = ["scores"] // topic-like channel
installation?.user = currentUser    // enables targeting by user later
try await installation?.save()
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching APNs directly.

// Android / Kotlin — Back4app Android SDK
// Register this install for push: token + channels live in an Installation
val installation = ParseInstallation.getCurrentInstallation()
installation.put("channels", listOf("scores")) // topic-like channel
installation.put("user", ParseUser.getCurrentUser()) // target by user later
installation.saveInBackground()
// deviceToken and deviceType are captured automatically — your backend
// now addresses this device without touching the push services directly.

Gerätetoken: die Adresse, die sich ständig ändert

Der Lebenszyklus des Tokens ist die eigentliche Aufgabe des Backends und der Teil, den Erklärseiten auslassen. Registrieren: Das Betriebssystem gibt ein Token pro App-Installation aus. Speichern: Die App gleicht es bei jedem Start mit Ihrem Backend ab – Token ändern sich bei Neuinstallation, Wiederherstellung und Löschen der Daten, und zwar stillschweigend. Adressieren: Sendungen sprechen Token an, einzeln oder über das Register. Ungültig werden: Sendungen an tote Token kommen mit spezifischen Fehlern zurück – 410 Gone von APNs, Unregistered-Token-Fehler von FCM – und FCM lässt Token verfallen, die rund neun Monate lang ungenutzt blieben. Bereinigen: bei diesen Fehlern sofort löschen. Backends, die den letzten Schritt überspringen, sammeln vergammelnde Token-Tabellen an, die Sendungen verschwenden, Zustellkennzahlen verzerren und Kampagnen verlangsamen – das Problem veralteter Token ist langweilig, kumulativ und der häufigste Push-Fehler in der Praxis.

APNs vs. FCM

Die praktische Folge der ersten Zeile: Jedes plattformübergreifende Backend bindet entweder beide Dienste an, nutzt FCM als einzige Oberfläche (indem es dort APNs-Zugangsdaten hinterlegt), oder gibt das ganze Problem an eine Plattform ab, die beide Sätze von Zugangsdaten hält – und genau dort landet der Back4app-Abschnitt.

Was Push nicht verspricht

Der ehrliche Vertrag, an einer Stelle zusammengetragen. Eine 200 vom Push-Dienst bedeutet zur Zustellung angenommen, nicht zugestellt. Geräte im Offline-Zustand sammeln keine getreue Warteschlange an: APNs behält nur die jüngste Benachrichtigung pro App; die Warteschlange von FCM läuft über eine TTL ab. Akku-Optimierer unter Android verzögern die Zustellung auf eine Weise, die Sie nicht steuern können; Nutzer können einen Kanal oder die gesamte App auf Systemebene stummschalten, unsichtbar für Ihr Backend. Stille Pushes – Hintergrundweckrufe ohne sichtbare Meldung – laufen auf einem winzigen Stundenbudget und werden darüber hinaus ohne Fehlermeldung verworfen, gemäß Apples eigener Dokumentation; sie sind Hinweise zum Aktualisieren, kein Synchronisierungsprotokoll. Die Entwurfsregel, die daraus folgt: Push ist das Tippen auf die Schulter – die Daten selbst reisen über Ihre API, wenn die App geöffnet wird, und alles, was ankommen muss, bekommt einen zweiten Kanal.

Web Push, kurz gefasst

Browser haben ihre eigene Kette standardisiert: Die Seite abonniert über die Push API mit Ihrem VAPID-Schlüsselpaar (RFC 8292 – der Server weist sich mit einem signierten Token aus, ohne Registrierung beim Hersteller), der Push-Dienst des Browsers liefert ein Abonnement zurück (Endpoint-URL + Schlüssel zur Verschlüsselung), und Ihr Server sendet verschlüsselte Payloads per POST an diesen Endpoint, gemäß Web-Push-Protokoll. Ein Service Worker empfängt das push-Ereignis und zeigt die Benachrichtigung an – bei geschlossener Website, auf dem Desktop womöglich bei geschlossenem Browser. Jeder Browserhersteller betreibt seinen eigenen Push-Dienst; die Endpoint-URL sagt Ihrem Server, wohin er senden soll. Die ehrliche Einschränkung: Unter iOS funktioniert Web Push nur für Web-Apps, die auf dem Home-Bildschirm installiert wurden.

Push vs. WebSockets vs. Live Queries

Sie ergänzen einander mit einer Grenze: Der Socket bedient den Nutzer, der auf den Bildschirm schaut; Push erreicht den Nutzer, der das Telefon weggelegt hat. Chat-Apps führen die Mischform täglich vor – Nachrichten strömen über die Verbindung, solange die App offen ist, und dieselbe Nachricht wird zur Push-Benachrichtigung, sobald sie es nicht mehr ist.

Typische Anwendungsfälle

• Nachrichten und Erwähnungen – der kanonische Push: Jemand braucht Sie, die App ist geschlossen.
• Transaktionsmeldungen – Bestellung versandt, Fahrt kommt an, Zahlung freigegeben: einzeilige Zusammenfassungen mit Deep Link in die App.
• Zeitkritische Auslöser – Spielstandwechsel, Preisalarme, Momente in der Nähe von Präsenz wie “X ist live”.
• Reaktivierung – sparsam eingesetzt und mit Abmeldung pro Kanal, sonst schalten Nutzer alles ab.
• Badge- und Zustandshinweise – das stille Budget dafür verwendet, die App vor dem Öffnen zum Aktualisieren anzustoßen.

Sollten Sie Push verwenden? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Zustellung ist eine Wahrscheinlichkeit, kein Versprechen. Entwerfen Sie Abläufe, die einen verpassten Push überstehen; gleichen Sie beim Öffnen der App ab.
• Berechtigungen sind einmaliges Kapital. Die Systemabfrage (explizit unter iOS und im Web, zur Laufzeit unter modernem Android) wird am ehesten angenommen, wenn sie im Kontext gestellt wird – und eine abgelehnte Abfrage ist kaum umkehrbar.
• Das Token-Register ist ein lebender Datenbestand. Beim Start abgleichen, bei Fehlern bereinigen – oder zusehen, wie die Zustellbarkeit leise verfällt.
• Payloads sind halb öffentlich. Benachrichtigungen erscheinen auf Sperrbildschirmen und reisen durch fremde Infrastruktur – Zusammenfassungen und IDs, niemals Geheimnisse.
• Zwei Systeme für Zugangsdaten, ein Feature. .p8-Schlüssel, Konsolen-Zugangsdaten, Ablaufzeit und Rotation – der Einrichtungsschmerz ist real, einmal pro Plattform, und genau das nehmen verwaltete Schichten ab.

Push-Benachrichtigungen mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Der Push-Dienst von Back4app verwandelt die gesamte Kette in Daten: Jede Installation registriert sich als Installation-Objekt – Gerätetoken, Plattform, Kanäle und ein Nutzerzeiger werden automatisch erfasst, wie die Client-Tabs zeigen – und ein einziger Sendeaufruf adressiert Kanäle (nach Art von Topics) oder eine beliebige Installation-Abfrage (“alle in scores unter Android, die diese Woche die App nicht geöffnet haben”), wobei die Plattform Ihre APNs- und FCM-Zugangsdaten hält und pro Gerät weiterleitet. Sendungen werden aus Cloud Code ausgelöst – ein afterSave auf Message, das an den Empfänger sendet, ist die Rückfallhälfte des Mischmusters –, aus geplanten Jobs oder aus der Konsole im Dashboard für einmalige Kampagnen. Token-Hygiene, doppelte Zugangsdaten und plattformspezifische Payload-Eigenheiten werden zum Verhalten der Plattform; Ihr Code entscheidet, wer und was, nicht wie.