Die App funktioniert einwandfrei — solange das Netz da ist. Im Keller, in der Tiefgarage, im Industriegebiet ohne Empfang: Funkstille. Wer Offline-First nicht von Anfang an einplant, baut zweimal.
Ein Servicetechniker meldet sich morgens im System an, nimmt seinen Auftrag entgegen und fährt zum ersten Kunden. Der Keller liegt tief, das Mobilfunknetz ist weg. Er öffnet die App — und sieht eine Fehlermeldung. Keine Verbindung zum Server. Kein Auftrag, keine Materialien, keine Dokumentation.
Das ist kein Extremfall. Das ist Alltag für Außendienst-Techniker, Lagermitarbeiter und Fahrer, die täglich in Gebäuden, Produktionshallen und Lagerkellern arbeiten. Und genau deshalb ist Offline-First keine optionale Funktion — es ist eine Grundvoraussetzung.
Offline-First bedeutet, dass die App so gebaut ist, als wäre eine Netzwerkverbindung die Ausnahme, nicht der Normalfall. Alle Daten, die der Nutzer braucht, liegen lokal auf dem Gerät. Die App funktioniert vollständig ohne Internet. Sobald wieder eine Verbindung besteht, synchronisiert sie die Änderungen im Hintergrund.
Das klingt einfach, ist es aber technisch nicht. Es braucht eine lokale Datenbank auf dem Gerät (typischerweise SQLite mit Room), eine Synchronisationslogik, die Konflikte erkennt und auflöst, und eine durchdachte Strategie dafür, welche Daten vorab geladen werden und welche bei Bedarf nachgeladen werden können.
Das ist der wichtigste Satz in diesem Artikel: Offline-First ist keine Funktion, die man am Ende dazubaut. Es ist eine Architekturentscheidung, die am Anfang getroffen werden muss.
Eine App, die von Anfang an auf einen Server-API-Aufruf bei jeder Aktion ausgelegt ist, hat keine lokale Datenschicht. Um Offline-Fähigkeit nachzurüsten, muss man die gesamte Datenverwaltung umschreiben. Das ist in der Praxis so aufwändig wie ein Neustart.
Wir sehen das regelmäßig: Ein Betrieb hat eine App in Auftrag gegeben, die im Büro einwandfrei funktioniert. Dann kommen die ersten Berichte aus dem Außendienst. Netz weg — App tot. Die Reaktion des Entwicklers: "Offline-Modus können wir noch einbauen." Was folgt, ist entweder eine teure Nachentwicklung oder eine App, die weiterhin unzuverlässig läuft.
Für eine typische Außendienst-App braucht es folgendes:
Lokale Datenbank. Aufträge, Kundendaten, Materialien, Preislisten — alles was der Techniker braucht, liegt auf dem Gerät. Beim App-Start oder bei bestehender Verbindung wird synchronisiert.
Offline-Erfassung. Alles, was der Nutzer eingibt — Zeiterfassung, Materialverbrauch, Fotos, Unterschriften, Notizen — wird lokal gespeichert und erst bei Verbindung übertragen.
Konfliktbehandlung. Was passiert, wenn zwei Techniker denselben Datensatz offline bearbeiten? Die Synchronisationslogik muss diese Fälle erkennen und sinnvoll auflösen — entweder automatisch nach Regeln oder mit einem Hinweis an den Nutzer.
Statusanzeige. Der Nutzer muss sehen, ob er online oder offline ist, wie viele ungesendete Datensätze noch ausstehen, und wann zuletzt synchronisiert wurde.
Wir haben für ein Serviceunternehmen mit 18 Außendienst-Technikern eine Android-App entwickelt. Die Techniker erfassen Aufträge, Materialverbrauch und Arbeitszeiten — täglich in Kellern, Tiefgaragen und Industriehallen ohne stabiles Netz.
Die App wurde von Anfang an mit Room als lokaler Datenbank und WorkManager für die Hintergrundsynchronisation gebaut. Seit Inbetriebnahme gab es keinen einzigen Ausfall durch Netzprobleme. Die Synchronisation läuft im Hintergrund, ohne dass der Techniker etwas tun muss.
Bevor eine Außendienst-App entwickelt wird, sollten diese Fragen beantwortet sein: Welche Daten müssen offline verfügbar sein? Wie groß ist das Datenvolumen, das vorab geladen werden muss? Wie oft und unter welchen Bedingungen findet die Synchronisation statt? Was passiert bei Konflikten? Wie werden Synchronisationsfehler dem Nutzer kommuniziert?
Wer diese Fragen vor der Entwicklung klärt, baut eine App, die im Alltag zuverlässig funktioniert. Wer sie nicht klärt, baut zweimal.
Wir entwickeln Offline-First von Anfang an — nicht als Nachbesserung.