Push ohne Google

Es gibt eine Stelle, an der fast jede App Daten an Google oder Apple schickt, auch die, die sonst vorbildlich alles im eigenen Backend hält: die Push-Benachrichtigung. „Neuer Auftrag für Sie", „Ihr Gerät ist bereit", „Bitte Schichtbericht abschließen". Jede dieser Nachrichten läuft über die Server von Apple, bei Android in aller Regel über Firebase Cloud Messaging von Google. Für die meisten Apps ist das in Ordnung. Für manche nicht, und dann kommt die Frage, mit der dieser Beitrag anfängt: Geht Push auch ohne?

Die Antwort ist zweigeteilt, und sie ist für Android anders als für iOS. Der Beitrag zeigt, welche Wege es gibt, wo ihre Grenzen liegen, und vor allem das Muster, mit dem man das Beste aus beiden Welten bekommt: die Zuverlässigkeit der Plattform-Dienste, ohne dass ein Inhalt jemals über fremde Server läuft. Er ergänzt den Beitrag über Push-Strategie, der beschreibt, was man sendet, um die Frage, worüber.

Für Entscheider: Worum es geht

• Bei nativen iOS-Apps führt für Remote-Push im Hintergrund kein Weg an Apples Push-Dienst (APNs) vorbei. Das ist technisch so gebaut und nicht verhandelbar.
• Auf Android ist Firebase (FCM) der Standard, aber nicht Pflicht. Es gibt einen offenen Standard (UnifiedPush) und für Firmengeräte eigene Verbindungen.
• Das entscheidende Muster: Über die Plattform-Dienste läuft nur ein Weckruf ohne Inhalt, nicht einmal die Vorgangsnummer. Die App fragt danach Ihr Backend: Was ist neu? Google und Apple sehen Zustellmetadaten, aber keinen Inhalt.
• Wer das große Firebase-Paket vermeiden will, nutzt FCM nur als Zusteller oder setzt auf verwalteten Geräten auf UnifiedPush, und schickt iOS-Push direkt an Apple, ohne Firebase dazwischen.
• Für Geräte, die dauerhaft im Firmennetz sind, geht auch ein eigener Kanal ohne beide, mit Grenzen bei Akku und Hintergrund.

Warum Push überhaupt über fremde Server läuft

Eine App, die nicht offen ist, bekommt vom Betriebssystem im Normalfall keine eigene Netzwerkverbindung. Das ist Absicht: Jede App, die im Hintergrund eine Verbindung offen hält, kostet Akku, und dreißig Apps mit je einer Verbindung würden das Handy in Stunden leeren. Android erlaubt Ausnahmen über Vordergrunddienste, dazu unten; iOS nicht. Deshalb halten Apple und Google auf jedem Gerät eine gemeinsame Verbindung offen, vom System selbst, zu ihren eigenen Servern. Wer eine App wecken will, schickt eine kleine Nachricht an diesen Server, der reicht sie über die eine Verbindung ans Gerät, und das System weckt die App. Das ist der ganze Trick, und er ist der Grund, warum Push so zuverlässig und so sparsam ist.

Die Kehrseite: Alles, was in dieser Nachricht steht, sieht der Betreiber der Verbindung. Bei Apple ist das Apple, bei Android Google, wenn die App Firebase nutzt. Wer „Patient Meyer, Zimmer 12, Sturz" als Push-Text verschickt, hat diesen Satz an Google übermittelt. Und wer das im Verarbeitungsverzeichnis nicht stehen hat, hat ein Problem, das die Datenschutzbeauftragte irgendwann findet.

Das Muster, das fast immer die Lösung ist: Wecken, dann holen

Bevor es um Alternativen zu den Plattform-Diensten geht, das Muster, das in neun von zehn Fällen reicht und das ich in jeder Business-App so baue. Die Push-Nachricht enthält keinen Inhalt. Konsequent gedacht enthält sie nicht einmal eine fachliche Kennung, denn auch „Vorgang 4711" ist eine Information. Sie sagt nur: Schau nach. Die App wird geweckt, fragt mit ihrer Anmeldung beim eigenen Backend, was neu ist, und zeigt dann die Benachrichtigung selbst an, mit dem Text aus dem Backend. Google beschreibt dieses Muster inzwischen selbst als datenschutzfreundliche Alternative zu Nachrichten mit Inhalt.

// Was über APNs oder FCM läuft: nur der Weckruf, kein Inhalt, keine Vorgangsnummer
{ "aps": { "content-available": 1 }, "type": "refresh" }

// Was die App danach tut (Pseudocode, iOS und Android gleich):
onPushReceived() {
  const neu = await backend.get('/was-ist-neu');        // eigener Server, eigene Anmeldung
  for (const v of neu) showLocalNotification(v.titel, v.kurztext); // Text nie über fremde Server
}

Was bei Apple und Google anfällt, sind Zustellmetadaten: Geräte- und App-Token, Zeitpunkte, Routing-Informationen. Das ist nicht nichts, und es gehört in die Datenschutzerklärung. Aber der Inhalt läuft ausschließlich zwischen App und Ihrem Backend. Für die Datenschutzerklärung ist das der Unterschied zwischen „Inhalte werden über Dienste von Google übermittelt" und „Google erhält Zustellmetadaten ohne Inhalt". Beides ist eine Übermittlung, die zweite lässt sich begründen, und keine von beiden ist ein Freibrief: Rechtsgrundlage, Auftragsverarbeitung und Transparenz bleiben Aufgaben, die das Muster nicht erledigt.

Die Grenze des Musters: Der Weckruf im Hintergrund ist auf beiden Plattformen nicht garantiert. Apple behandelt Hintergrund-Benachrichtigungen ausdrücklich mit niedriger Priorität, garantiert ihre Zustellung nicht, drosselt sie und empfiehlt, nicht mehr als etwa zwei bis drei pro Stunde zu senden. Wurde die App vom Nutzer oder vom System beendet, können zurückgehaltene Weckrufe ganz verworfen werden, bis die App das nächste Mal gestartet wird. Wenn das Gerät im Stromsparmodus ist oder das System die App als selten genutzt einstuft, kann der Weckruf verzögert oder verworfen werden. Für „neuer Auftrag" ist das egal, der wird beim nächsten Öffnen geladen. Für „Alarm, sofort reagieren" nicht. Dann bleibt entweder ein sichtbarer Push mit einem inhaltsarmen Text („Neue dringende Meldung, bitte App öffnen"), oder einer der Wege unten.

Android: Es gibt Alternativen

FCM nur als Zusteller, ohne das große Firebase-Paket

Der erste Schritt ist kleiner, als er klingt. Viele Apps nutzen Firebase nicht nur für Push, sondern binden weitere Firebase-Produkte ein, Analytics, Crash-Reporting, Login, Datenbank, und alles läuft in einem Projekt zusammen. Für Push braucht es davon nur den Messaging-Dienst. Das eigene Backend spricht direkt die FCM-HTTP-v1-Schnittstelle an; ein minimales Firebase-Projekt bleibt als Zustelladresse und für die Zugangsdaten nötig, aber darin läuft nichts zusammen außer der Zustellung. Analytics, Crashlytics, Auth oder Firestore müssen deshalb nicht Bestandteil der App sein. Google bleibt der Zusteller und sieht mit dem Weckruf-Muster nur Metadaten.

UnifiedPush: Der offene Standard

UnifiedPush ist eine offene Spezifikation, bei der der Nutzer selbst wählt, welche App die eine Hintergrundverbindung hält. Ein sogenannter Distributor (etwa ntfy oder NextPush) läuft auf dem Gerät, hält die Verbindung zu einem Server, den der Betrieb selbst betreiben kann, und reicht Nachrichten an alle Apps weiter, die sich bei ihm registriert haben. Kein Google beteiligt, kein Firebase, der Server steht bei Ihnen.

Der Haken: Der Distributor muss auf dem Gerät installiert sein, und die Nutzer müssen ihn einrichten. Auf Privatgeräten von Außendienstlern ist das eine Hürde. Auf Firmengeräten, die über eine Geräteverwaltung eingerichtet werden, ist es ein Häkchen mehr im Profil, und dann ist UnifiedPush ein sehr guter Weg für Betriebe, die den Push-Server selbst kontrollieren wollen. Betriebsseitig einfacher und robuster ist oft FCM über Managed Google Play; welcher Weg passt, ist eine Abwägung zwischen Kontrolle und Betriebsaufwand. Die Bibliotheken für die App-Seite sind ausgereift, und wer zusätzlich FCM als Rückfall einbindet, versorgt beide Gerätearten aus einem Code.

Eigene Verbindung: MQTT oder WebSocket im Vordergrunddienst

Für Geräte, die dauerhaft im Firmennetz sind und ständig genutzt werden, Handscanner im Lager, Tablets am Empfang, Geräte im Kiosk-Modus, geht auch die direkte Lösung: Die App hält selbst eine Verbindung zum Backend, über MQTT oder WebSocket, in einem Vordergrunddienst mit dauerhafter Benachrichtigung („App aktiv"). Kein Push-Dienst, keine Registrierung, Zustellung ohne Umweg. Für Alarme, die schnell ankommen müssen, kann das der passende Weg sein, mit Vorbehalt.

Der Vorbehalt: Aktuelle Android-Versionen schränken Vordergrunddienste stark ein. Je nach Einsatz braucht es den passenden Diensttyp, Berechtigungen und die Beachtung der Play-Richtlinien, und die Ausnahme von der Akku-Optimierung ist kein Freifahrtschein. Praktisch funktioniert der Weg unter zwei Bedingungen: Das Gerät ist am Strom oder wird täglich geladen, und die Geräteverwaltung nimmt die App ausdrücklich von der Akku-Optimierung aus. Gerade Geräte einiger Hersteller, Xiaomi, Oppo und ähnliche, beenden auch Vordergrunddienste, wenn die Verwaltung sie nicht ausnimmt, das ist in der Praxis der häufigere Killer als das nackte Android. Für Privatgeräte ist dieser Weg nicht geeignet. Für einen Gerätepark im Betrieb ist er oft der beste, und der Beitrag über MDM und Kiosk-Apps beschreibt die Einrichtung.

Geräte ohne Google-Dienste

Manche Firmengeräte haben keine Google Play Services, etwa bestimmte Huawei-Geräte, AOSP-basierte Industrie-Tablets oder spezielle Rugged-Scanner. Dort funktioniert FCM schlicht nicht. Wer für solche Geräte baut, braucht ohnehin einen der beiden anderen Wege, und stellt meist fest, dass er auch für den Rest der Flotte reicht.

iOS: Kein Weg an Apple vorbei, aber ein guter

Apple lässt auf dem iPhone keine App eine dauerhafte Hintergrundverbindung halten, und keine App darf die eine Systemverbindung nutzen außer über APNs. Es gibt keinen UnifiedPush für iOS, keine Vordergrunddienste im Android-Sinn, keinen Weg außenherum. Wer bei einer nativen iOS-App eine Nachricht zustellen will, wenn die App nicht offen ist, geht über Apple.

Was man aber beeinflussen kann: ob Firebase dazwischen sitzt. Viele Apps schicken auch iOS-Push über FCM, das die Nachricht dann an Apple weiterreicht, weil das im Backend bequemer ist. Damit sind sowohl Google als auch Apple technische Dienstleister im Zustellweg. Wer FCM auf iOS nicht aus anderen Gründen braucht, kann APNs direkt ansprechen, mit einem Schlüssel aus dem Entwicklerkonto und einer Schnittstelle, die in jeder Sprache schnell eingebunden ist, und entfernt damit einen Anbieter aus der Kette. Mit dem Wecken-dann-holen-Muster sieht auch Apple nur Metadaten.

# Direkt an APNs, ohne Firebase (Beispiel mit curl und dem .p8-Schlüssel aus dem Entwicklerkonto)
curl -v --http2 \
  -H "authorization: bearer $JWT" \
  -H "apns-topic: de.musterbetrieb.portal" \
  -H "apns-push-type: background" \
  -H "apns-priority: 5" \
  -d '{"aps":{"content-available":1},"type":"refresh"}' \
  https://api.push.apple.com/3/device/$DEVICE_TOKEN

Was iOS zusätzlich bietet, sind Ausnahmen für bestimmte Fälle: zeitkritische Benachrichtigungen für Wichtiges, das den Fokusmodus durchbrechen darf, und kritische Warnungen, die auch bei Stummschaltung oder Fokus einen Ton ausgeben. Die brauchen eine besondere Berechtigung, die Apple auf Antrag prüft und nicht automatisch erteilt; wer sie für echte Alarme, etwa im Sicherheitsdienst, bekommt, hat den einzigen iOS-Weg, der zuverlässig durchdringt. Dazu die Hintergrundaktualisierung in Intervallen, die das System selbst wählt. Nichts davon ersetzt einen eigenen Kanal, aber es reicht für die meisten Business-Fälle.

Der dritte Weg: Web Push für Anwendungen ohne App

Wer keine native App hat, sondern eine Webanwendung oder eine PWA, hat seit einigen Jahren Web Push: einen offenen Standard, bei dem der Browser die Zustellung übernimmt und die Nachrichten mit einem Schlüsselpaar des Betreibers verschlüsselt sind. Der Push-Dienst des Browserherstellers sieht den Inhalt nicht, das ist im Standard eingebaut. Seit iOS 16.4 funktioniert das auch auf dem iPhone, wenn die Webanwendung auf dem Homescreen liegt. Für Anwendungen, die ohnehin im Browser laufen, ist das ein sehr datensparsamer Weg, und ob eine PWA für Sie reicht, steht im Beitrag PWA vs. Native Apps.

Meine Empfehlung nach Fall

Fall	Android	iOS
Privatgeräte, gemischte Nutzer	FCM nur als Zusteller, Weckruf-Muster	APNs direkt, Weckruf-Muster
Firmengeräte mit Geräteverwaltung	UnifiedPush mit eigenem Server, FCM als Rückfall	APNs direkt
Geräte im Kiosk-Modus, am Strom, im Firmennetz	Eigene MQTT-Verbindung im Vordergrunddienst	APNs direkt, bei Alarmen zeitkritische Benachrichtigungen
Webanwendung oder PWA	Web Push, Ende-zu-Ende verschlüsselt nach Standard

Die häufigsten Fehler

• Inhalt im Push. Patientennamen, Auftragsdetails, Beträge im Klartext an Google und Apple. Das Weckruf-Muster ist überschaubarer Aufwand und behebt es.
• Mehr Firebase-Produkte eingebunden als nötig. Für Push reicht der Messaging-Dienst; Analytics, Crashlytics oder andere Module gehören nur in die App, wenn sie gebraucht und datenschutzseitig bewertet sind.
• iOS über FCM geleitet, ohne Grund. Zwei Dienstleister im Zustellweg statt einem, ohne Vorteil.
• Eigene Verbindung auf Privatgeräten. Android beendet sie, die Nutzer beschweren sich über den Akku, und die Nachrichten kommen trotzdem nicht an.
• Weckruf als garantiert behandelt. Für Alarme braucht es sichtbare Nachrichten oder einen eigenen Kanal, nicht Hoffnung auf den Hintergrundmodus.
• Push-Schlüssel beim Entwickler statt beim Betrieb. Der APNs-Schlüssel gehört ins Entwicklerkonto des Betriebs, und er lässt sich nach der Erstellung nicht erneut herunterladen; der Server für UnifiedPush gehört in die Infrastruktur des Betriebs. Warum das entscheidend ist, steht im Beitrag über die App-Übergabe.

Checkliste: Wie laufen Ihre Benachrichtigungen?

• ☐ Welche Inhalte stehen heute im Push-Text, und wer sieht sie unterwegs?
• ☐ Nutzt die App das Weckruf-Muster, oder schickt sie Inhalte?
• ☐ Läuft iOS-Push direkt über Apple oder über Firebase?
• ☐ Welche Teile von Firebase sind eingebunden, und werden sie gebraucht?
• ☐ Sind die Geräte verwaltet, sodass UnifiedPush oder eine eigene Verbindung möglich ist?
• ☐ Gibt es Nachrichten, die in Sekunden ankommen müssen, und wie ist das abgesichert?
• ☐ Steht die Push-Übermittlung mit dem tatsächlichen Umfang in der Datenschutzerklärung?

Fazit: Der Weckruf gehört den Plattformen, der Inhalt Ihnen

Push ganz ohne Google und Apple gibt es bei nativen Apps auf dem iPhone nicht. Auf Android geht es, technisch auch auf einem privaten Gerät, wenn der Nutzer selbst einen UnifiedPush-Distributor einrichtet; betrieblich beherrschbar wird es erst mit verwalteten Geräten. Das muss man wissen und ehrlich sagen. Aber der Inhalt der Nachrichten muss nie über fremde Server laufen, auf keiner Plattform. Das Weckruf-Muster ist klein, es ist in jeder Business-App umsetzbar, und es verwandelt „Google liest unsere Aufträge" in „Google weiß, dass die App nachschauen soll". Die Datenschutzhausaufgaben, Rechtsgrundlage, Verträge, Transparenz, bleiben trotzdem, nur mit deutlich weniger Daten darin. Wer darüber hinaus will, hat auf Android echte Alternativen und auf iOS zumindest die Wahl, wie viele Anbieter dazwischensitzen. Ich baue Push seit Jahren nach diesem Prinzip: so wenig wie möglich über den Zustelldienst, so viel wie nötig über das eigene Backend. Das macht nicht automatisch DSGVO-konform, aber die Datenschutzdiskussion erheblich einfacher.