Offline-First-Apps: Architektur für Apps ohne Netzabhängigkeit

Kurz gefasst: Eine Offline-First-App arbeitet zuerst mit einer lokalen Datenbank auf dem Gerät und gleicht Änderungen mit dem Server ab, sobald eine Verbindung besteht. Nutzer können so im Keller, auf der Baustelle oder im Funkloch ohne Unterbrechung weiterarbeiten. Die eigentliche Arbeit steckt in der Synchronisation: eine Warteschlange für ausstehende Änderungen, eindeutige IDs, klare Regeln für Konflikte und eine Oberfläche, die den Sync-Status ehrlich anzeigt.

Wann sich Offline-First lohnt

Nicht jede App braucht eine Offline-Architektur. Ein Newsportal oder ein Buchungstool, das ohnehin Live-Daten vom Server benötigt, kommt mit gutem Caching aus. Offline-First lohnt sich, wenn Menschen unter schlechten Netzbedingungen arbeiten müssen und Datenverlust teuer ist: Außendienst und Servicetechniker, Inventur im Lager, Aufmaß auf der Baustelle, Inspektionen in Industrieanlagen, Pflegedokumentation. In diesen Fällen ist eine App, die bei fehlendem Netz einen Fehler zeigt, im Alltag kaum brauchbar.

Auch bei gutem Netz bringt der Ansatz Vorteile. Weil die App aus der lokalen Datenbank liest, reagiert sie sofort, ohne auf den Server zu warten.

Die Grundarchitektur einer Offline-First-App

Die lokale Datenbank als Quelle der Wahrheit

Die Oberfläche liest und schreibt ausschließlich gegen die lokale Datenbank. Bei React Native kommt dafür meist SQLite zum Einsatz, oft mit einer Bibliothek wie WatermelonDB darüber. Flutter-Projekte nutzen zum Beispiel Drift, native Apps Room unter Android und Core Data oder SwiftData unter iOS. Der Server ist der Ort, an dem die Daten aller Geräte zusammenlaufen, die App ist aber nicht auf ihn angewiesen, um zu funktionieren.

Die Sync-Warteschlange

Jede Änderung auf dem Gerät wird in der lokalen Datenbank gespeichert und zusätzlich als Eintrag in eine Warteschlange (Outbox) geschrieben. Ein Sync-Prozess arbeitet diese Warteschlange ab, sobald Netz verfügbar ist, und holt umgekehrt neue Daten vom Server. Wichtig: Jede Änderung braucht eine eindeutige ID, damit der Server doppelt gesendete Anfragen erkennt und nur einmal verarbeitet. Bei instabilen Verbindungen kommt es regelmäßig vor, dass eine Anfrage ankommt, die Antwort aber verloren geht.

Eindeutige IDs auf dem Gerät erzeugen

Datensätze, die offline entstehen, brauchen sofort eine ID, nicht erst, wenn der Server sie vergibt. UUIDs, die auf dem Gerät erzeugt werden, lösen das Problem. Sonst müssen Verweise zwischen Datensätzen nach dem Sync umgeschrieben werden, was eine häufige Fehlerquelle ist.

Konflikte erkennen und auflösen

Bearbeiten zwei Personen denselben Datensatz offline, entsteht beim Sync ein Konflikt. Die einfachste Strategie ist „Last Write Wins“: Die zuletzt gespeicherte Änderung gewinnt. Das ist für viele Felder vertretbar, kann aber Arbeit überschreiben.

Feiner ist das Zusammenführen auf Feldebene. Hat eine Person die Telefonnummer geändert und die andere die Adresse, bleiben beide Änderungen erhalten. Für echte Konflikte im selben Feld kann die App den Nutzer entscheiden lassen. Für gemeinsam bearbeitete Dokumente gibt es CRDTs, Datenstrukturen, die sich automatisch konfliktfrei zusammenführen lassen. Sie sind mächtig, aber für typische Geschäftsdaten oft mehr als nötig.

Gelöschte Datensätze brauchen besondere Aufmerksamkeit. Statt sie sofort zu entfernen, markiert man sie als gelöscht (Tombstone), damit andere Geräte die Löschung beim nächsten Sync mitbekommen.

Wer diese Logik nicht selbst bauen möchte, findet fertige Sync-Lösungen wie PowerSync, ElectricSQL, Couchbase Lite oder die Offline-Persistenz von Firestore. Die Wahl hängt stark vom Backend ab und gehört an den Projektanfang, ähnlich wie die Frage nach dem Framework, die wir im Vergleich React Native vs. Flutter beleuchten.

Oberfläche, Sicherheit und Tests

Den Sync-Status sichtbar machen

Nutzer sollten erkennen, ob ihre Daten schon übertragen wurden. Ein kleines Symbol für „gespeichert auf dem Gerät“ und „synchronisiert“ schafft Vertrauen. Schlägt ein Sync dauerhaft fehl, braucht es eine verständliche Meldung, keine stille Endlosschleife.

Daten auf dem Gerät schützen

Lokal gespeicherte Kundendaten sind bei Verlust oder Diebstahl des Geräts ein Risiko. Verschlüsseln Sie die Datenbank, etwa mit SQLCipher, und legen Sie Schlüssel im Keychain bzw. Keystore ab. Weitere Punkte haben wir unter Sicherheitslücken in mobilen Apps zusammengestellt.

Unter echten Bedingungen testen

Flugmodus ist nur der einfachste Fall. Schwieriger sind langsame, abbrechende Verbindungen und Apps, die mitten im Sync vom Betriebssystem beendet werden. Hintergrund-Synchronisation ist unter iOS und Android eingeschränkt und nicht garantiert, die App muss also auch beim nächsten Start zuverlässig weitermachen.

Häufige Fragen (FAQ)

Geht Offline-First auch mit einer Web-App?

Teilweise. Progressive Web Apps können mit Service Workern und IndexedDB offline arbeiten, haben aber engere Grenzen beim Speicher und bei Hintergrundprozessen, vor allem unter iOS. Wann eine PWA reicht, beschreiben wir in Progressive Web Apps: Lohnen sie sich?.

Wie viele Daten kann eine App offline speichern?

Native Apps können in der Regel große Datenmengen lokal halten, begrenzt vor allem durch den freien Speicher des Geräts. Sinnvoll ist trotzdem, nur die Daten zu synchronisieren, die der jeweilige Nutzer braucht, etwa die Aufträge seiner Region.

Kann ich eine bestehende App nachträglich offlinefähig machen?

Das ist möglich, aber aufwendiger als ein Offline-First-Konzept von Beginn an. Meist müssen Datenzugriff, ID-Vergabe und Teile der Server-API umgebaut werden. Bei Apps mit klarem Offline-Bedarf lohnt sich die Entscheidung daher früh.

Fazit

Offline-First ist vor allem eine Entscheidung über die Datenhaltung, weniger über die Oberfläche. Wer lokale Datenbank, Warteschlange und Konfliktregeln von Anfang an sauber plant, bekommt eine App, die im Funkloch genauso zuverlässig arbeitet wie im Büro und sich obendrein schneller anfühlt.

Wenn Ihr Team draußen arbeitet und eine App braucht, die ohne Netz funktioniert, sprechen Sie mit uns über App-Entwicklung.