React Native und Hintergrundaufgaben: Was Basis-Tutorials nie sagen

Die meisten React Native-Anleitungen hören auf, wenn es “auf dem Emulator funktioniert”. Das Problem ist, dass in der Produktion — auf einem echten Telefon, mit iOS, das aggressiv den Speicher verwaltet, und Android, das je nach Hersteller variiert — Ihre Hintergrundaufgaben stoppen. Lautlos. Ohne Log. Ohne sichtbaren Fehler.

Ergebnis: Datensynchronisierung, die nicht mehr stattfindet, Benachrichtigungen, die nicht ankommen, Fetch, der nach 3 Tagen Nutzung fehlschlägt. Und ein Nutzer, der deinstalliert.

Das haben uns 15 Jahre beim Aufbau von Web- und Mobile-Anwendungen gelehrt — und was die offizielle Dokumentation nicht ausreichend dokumentiert.

---

Warum Hintergrundaufgaben wirklich fehlschlagen (und es nicht Ihr Code ist)

Der erste Fehler, den die meisten Entwickler machen: den Bug im Code suchen. Oft ist der Code korrekt. Es ist das Betriebssystem, das gegen Sie arbeitet.

iOS und Android haben radikal entgegengesetzte Philosophien bei der Verwaltung von Hintergrundprozessen. iOS ist drakonisch: Die Anwendung hat keine Ausführungsgarantie außerhalb der Fenster, die das System explizit gewährt. Android ist theoretisch permissiver, aber Hersteller-Overlays (Samsung, Xiaomi, Huawei) fügen ihre eigenen Akkuoptimierungsschichten hinzu, die Prozesse ohne Vorwarnung beenden.

Was wir konkret bei unseren Kunden sehen, die React Native-Apps entwickeln:

• Ein BackgroundFetch-Task, der in der Entwicklung funktioniert, aber nach 72 Stunden in der Produktion auf iOS aufhört
• Ein Hintergrund-Geolocation-Dienst, der stoppt, sobald ein Xiaomi-Nutzer den “Energiesparmodus” aktiviert
• Worker, die auf einem Pixel (reines Android) perfekt laufen, aber auf einem Galaxy S24 sterben

Die React Native-Dokumentation erwähnt diese Einschränkungen. Sie sagt Ihnen nicht, wie Sie sie robust umgehen können.

---

Die drei Ansätze — und warum zwei Sie enttäuschen werden

BackgroundFetch: nützlich, aber begrenzt

react-native-background-fetch ist die am besten dokumentierte Lösung. Sie funktioniert auf iOS und Android, ist einfach einzurichten, und wird Ihnen falsche Hoffnungen machen.

Auf iOS beträgt das Mindestintervall 15 Minuten — und das ist ein Vorschlag, keine Garantie. Das System entscheidet, wann der Task ausgeführt wird, basierend auf dem App-Nutzungsverlauf, dem Akkustand und der Netzwerkverbindung. In der Praxis werden Ihre Tasks zwischen 15 Minuten und mehreren Stunden nach der geplanten Zeit ausgeführt.

Das ist kein Bug. Das ist das dokumentierte Verhalten von iOS.

Für unkritische Synchronisierungen (Inhaltsaktualisierung, Datenvorcaching) ist das akzeptabel. Für alles, was pünktlich sein muss — Zahlung, Alarm, Bestandsaktualisierung — ist es unzureichend.

Headless JS Tasks auf Android: mächtig, fragil

Android erlaubt über HeadlessJS das Ausführen von JavaScript auch wenn die App im Hintergrund ist. Das ist zuverlässiger als BackgroundFetch auf “reinen” Android-Geräten. Das Problem kommt mit den Hersteller-Overlays.

Was man Ihnen nie in Agenturen sagt: Xiaomi-, Oppo- und Huawei-Telefone stellen einen erheblichen Marktanteil dar. Und alle diese Hersteller haben Akkuverwaltungssysteme, die Hintergrundprozesse beenden, es sei denn, der Nutzer geht manuell in die Einstellungen und deaktiviert die “Akkuoptimierung” für Ihre App.

Wie viele Nutzer tun das? Sehr wenige.

Silent Push Notifications: die echte Lösung für Echtzeit

Wenn Ihr Bedarf darin besteht, eine präzise Aktion zu einem präzisen Zeitpunkt auszulösen, hören Sie auf, gegen die Einschränkungen von Hintergrundaufgaben zu kämpfen. Verwenden Sie Silent Push Notifications.

Das Prinzip: Ihr Server sendet eine Push-Benachrichtigung ohne sichtbaren Inhalt (Silent Push Notification). Die App wacht auf, führt ihre Aufgabe aus, schläft wieder ein. iOS garantiert 30 Sekunden Ausführungszeit. Android ist großzügiger.

Das ist die Architektur, die WhatsApp, Slack und die meisten kritischen Apps verwenden. Nicht weil es elegant ist — weil es in der Produktion funktioniert.

---

Der Stack, der wirklich in der Produktion funktioniert

Nach dem Testen verschiedener Ansätze in echten Projekten empfehlen wir je nach Anwendungsfall Folgendes.

Für unkritische periodische Synchronisierung (Inhaltsaktualisierung, Statistiken, Logs): Verwenden Sie react-native-background-fetch mit einer Retry-Strategie. Nehmen Sie nie an, dass der Task ausgeführt wurde. Überprüfen Sie serverseitig und re-synchronisieren Sie beim App-Öffnen wenn nötig.

Für servergesteuerte Aktionen (Benachrichtigungen, kritische Datenaktualisierungen): Silent Push Notifications über Firebase Cloud Messaging (FCM) auf Android, APNs auf iOS. Testen Sie unbedingt auf echten Geräten, nicht nur auf dem Simulator.

Für kontinuierliche Geolocation: react-native-background-geolocation von Transistor Software ist die Referenz. Es ist kostenpflichtig (ca. 400$/Jahr für eine kommerzielle App). Es ist auch die einzige Bibliothek, die iOS/Android-Randfälle in der Produktion korrekt behandelt. Wenn Ihre App von Geoloc abhängt, ist das eine Investition, keine Kosten.

“Die Zuverlässigkeit einer Mobile-App wird daran gemessen, was passiert, wenn niemand zuschaut — wenn der Bildschirm aus ist, der Akku bei 15%, und der Nutzer in einem Gebiet mit schwachem Signal.” — Prinzip, das wir systematisch bei Mobile-Audits anwenden

---

Konfigurationsfehler, die teuer werden

Hier wird es interessant — und wo die meisten Projekte entgleisen.

iOS Capabilities vergessen

Auf iOS muss jede Art von Hintergrundaufgabe in Info.plist deklariert und in den Xcode Capabilities aktiviert sein. Background Fetch, Remote Notifications, Background Processing — wenn Sie eines dieser Flags vergessen, wird der Task in der Entwicklung ausgeführt (wo die Einschränkungen gelockert sind) und schlägt in der Produktion fehl.

Das ist eine der häufigsten Ursachen für “es funktionierte vor dem Produktionsstart”.

Doze Mode und App Standby auf Android ignorieren

Android 6+ führt den “Doze Mode” ein: Wenn das Gerät inaktiv ist, werden Hintergrundjobs zusammengefasst und verzögert. Android 8+ fügt noch strengere Einschränkungen für Hintergrunddienste hinzu.

Die offizielle Lösung: WorkManager über eine native Bibliothek verwenden. react-native-background-fetch macht das seit Version 4 unter der Haube. Wenn Sie eine ältere Version oder eine nicht gepflegte Bibliothek verwenden, sind Sie exponiert.

Überprüfen Sie Ihre Abhängigkeiten. Ein schnelles npm outdated kann Überraschungen enthüllen.

Timeouts nicht verwalten

iOS gibt Ihnen 30 Sekunden. Android ist variabel. Wenn Ihr Task dieses Limit überschreitet — langsamer Netzwerk-Fetch, schwere Verarbeitung, langsame SQLite-Datenbank — beendet das System ihn. Ohne Ausnahme. Ohne sauberes Log.

Die Regel: Jeder Hintergrundtask muss einen expliziten Timeout haben. Wenn er in 25 Sekunden nicht fertig ist, muss er sich sauber selbst beenden, seinen Zustand speichern und im nächsten Zyklus fortfahren.

---

Unter realen Bedingungen testen: das Protokoll, das wir verwenden

Emulatoren reproduzieren Hintergrundverhalten nicht. Punkt. Sie müssen auf echten Geräten mit echten Einschränkungen testen.

Unser Mindestprotokoll vor dem Veröffentlichen einer Background-Processing-Funktion:

Gerät 1 — Reines Android: Ein Pixel oder ein Android One-Gerät. Validiert, dass Ihr Code ohne Hersteller-Overlay funktioniert.

Gerät 2 — Samsung Galaxy: Testet das Verhalten mit dem Samsung-Overlay, dem verbreitetsten.

Gerät 3 — iPhone mit aktuellem iOS: Validiert Apple-Einschränkungen, die sich mit jeder Hauptversion weiterentwickeln.

Für jedes Gerät das Testszenario:

1. App starten, in den Hintergrund legen
2. Bildschirm ausschalten, 30 Minuten warten
3. Überprüfen, ob der Task ausgeführt wurde
4. Mit Akku unter 20% wiederholen
5. Mit aktiviertem Energiesparmodus wiederholen

Es ist mühsam. Es ist das, was eine App, die in der Produktion standhält, von einer App unterscheidet, die um 3 Uhr nachts Support-Tickets generiert.

---

Die Resilience-Strategie: nie annehmen, dass der Task ausgeführt wurde

Hier ist der wichtigste Mentalitätswechsel: Entwerfen Sie Ihre App so, als ob Hintergrundaufgaben möglicherweise nie ausgeführt werden.

Das impliziert:

Eine Vordergrund-Synchronisierung als Fallback. Bei jedem App-Öffnen überprüfen, ob Daten synchronisiert werden müssen. Wenn der Hintergrundtask fehlgeschlagen ist, holt der Vordergrund den Rückstand auf.

Ein Zeitstempel der letzten Ausführung. Lokal speichern, wann der Task zuletzt ausgeführt wurde. Wenn die Verzögerung anomal ist, eine sofortige Re-Synchronisierung auslösen.

Serverseitige Indikatoren. Nicht nur dem Client vertrauen. Ihr Server muss wissen, ob ein Gerät “im Rückstand” ist und seine Antworten entsprechend anpassen.

Das ist kein Over-Engineering. Das ist, was alle kritischen Mobile-Apps tun. Gmail, Notion, Slack — alle haben eine Vordergrund-Wiederholungslogik, weil sie alle wissen, dass Background-Processing nicht zu 100% zuverlässig ist.

“Ein robustes System ist nicht eines, das nie fällt. Es ist eines, das selbst wieder aufsteht.”

---

Was das konkret für Ihr Projekt bedeutet

Wenn Sie eine React Native-App mit Hintergrundbedürfnissen entwickeln, hier sind die drei umsetzbaren Punkte, die Sie sich merken sollten:

1. Wählen Sie Ihren Stack basierend auf Ihrem tatsächlichen Anwendungsfall, nicht basierend auf dem ersten Medium-Tutorial, das Sie gelesen haben. BackgroundFetch für das Unkritische, Silent Push für Echtzeit, spezialisierte Bibliotheken für Geoloc.

2. Testen Sie auf echten Geräten mit echten Einschränkungen. Emulator = falsche Sicherheit. Ein Samsung im Energiesparmodus wird Ihnen in 30 Minuten mehr Bugs offenbaren als 10 Stunden auf dem Simulator.

3. Für Fehler entwerfen. Ihr Hintergrundtask wird fehlschlagen. Nicht immer, nicht auf allen Geräten, aber er wird fehlschlagen. Ihre Architektur muss das antizipieren.

---

Fazit: Zuverlässigkeit wird gebaut, nicht angenommen

Background-Processing in React Native ist kein Code-Problem. Es ist ein Architektur-, Konfigurations- und Testproblem unter realen Bedingungen.

Basis-Tutorials zeigen Ihnen, wie man einen Task ausführt. Sie zeigen Ihnen nicht, wie man einen Task zuverlässig, auf allen Geräten, für 18 Monate Produktion ausführt. Dort liegt der Unterschied zwischen einer App, die Nutzer behalten, und einer App, die sie deinstallieren.

Bei GDM-Pixel, wenn wir bei einem Audit einer Mobile-App eingreifen, die “nicht mehr wie früher funktioniert”, sind Hintergrundaufgaben unter den ersten drei Dingen, die wir überprüfen. Weil wir wissen, dass dort die stillen Bugs leben.

Ihre React Native-App hat erratisches Verhalten in der Produktion? Wir machen technische Mobile-Audits — ehrliche Diagnose, umsetzbare Empfehlungen, ohne Ihnen eine Neuentwicklung zu verkaufen, wenn sie nicht notwendig ist. Kontaktieren Sie uns, um darüber zu sprechen.