Offline-first beschreibt eine Art, Anwendungen zu bauen, bei der das Gerät und nicht der Server die erste Anlaufstelle für Daten ist. Die Anwendung liest und schreibt zunächst lokal, zeigt Änderungen sofort an und gleicht sie im Hintergrund mit dem Server ab, sobald eine Verbindung besteht. Eine fehlende Verbindung ist in diesem Modell kein Ausnahmezustand mit Fehlermeldung, sondern eine Situation, mit der die Anwendung jederzeit umgehen kann.
Offline-first ist mehr als ein Zwischenspeicher
Oft wird Offline-Fähigkeit mit einem Service Worker gleichgesetzt, der Dateien zwischenspeichert. Das sorgt dafür, dass sich eine Anwendung ohne Netz öffnen lässt, löst aber das eigentliche Problem nicht: Was passiert mit Daten, die der Nutzer ohne Verbindung erfasst oder ändert? Offline-first beantwortet diese Frage im Datenmodell. Erfassungen werden lokal gespeichert, in eine Warteschlange gelegt und später übertragen; die Anwendung weiss jederzeit, welche Änderungen noch nicht beim Server angekommen sind.
Davon zu unterscheiden ist eine «offline-tolerante» Anwendung, die bei Verbindungsabbruch nur verhindert, dass Eingaben verloren gehen, ansonsten aber auf den Server angewiesen ist. Für viele Geschäftsanwendungen reicht das. Offline-first lohnt sich dort, wo Menschen regelmässig ohne Netz arbeiten: auf Baustellen, in Lagerhallen, in Kellern, bei Kunden zu Hause, in ländlichen Regionen.
Die Bausteine einer Offline-first-Anwendung
Im Browser dient meist IndexedDB als lokale Datenbank, weil sie strukturierte Daten in grösserem Umfang speichern kann. Darüber liegt eine Synchronisationsschicht, die Änderungen sammelt, bei Verbindung an den Server sendet und neue Daten vom Server einspielt. Die Oberfläche arbeitet optimistisch: Eine Erfassung erscheint sofort als gespeichert, wird aber sichtbar als «noch nicht übertragen» markiert, bis der Server sie bestätigt hat.
Auf der Serverseite braucht es Schnittstellen, die mit verspätet und mehrfach eintreffenden Daten umgehen können. Jede Änderung trägt eine eindeutige Kennung, damit eine wiederholte Übertragung nach einem Abbruch nicht zu doppelten Einträgen führt. Dieses Prinzip heisst Idempotenz und ist für Offline-first unverzichtbar.
Konflikte sind der eigentliche Aufwand
Sobald mehrere Personen oder Geräte dieselben Daten offline ändern können, entstehen Konflikte. Zwei Monteure ändern denselben Auftrag, beide ohne Netz, und gleichen eine Stunde später ab. Welche Änderung gilt? Die einfachste Regel lautet «die letzte Änderung gewinnt» — einfach umzusetzen, aber mit dem Risiko, dass Arbeit stillschweigend verloren geht. Besser ist es oft, auf Feldebene zusammenzuführen: Ändert der eine die Uhrzeit und der andere die Notiz, bleiben beide Änderungen erhalten.
Für echte Kollisionen auf demselben Feld braucht es eine fachliche Regel oder eine Rückfrage an den Nutzer. Für bestimmte Datentypen gibt es spezialisierte Verfahren wie konfliktfreie replizierte Datentypen, die Änderungen mathematisch zusammenführen; sie sind mächtig, aber nicht für jede Anwendung angemessen. Die wichtigste Erkenntnis: Konfliktregeln sind fachliche Entscheidungen. Sie gehören ins Konzept und werden mit den Menschen festgelegt, die die Daten nutzen.
Was Nutzer sehen müssen
Eine Offline-first-Anwendung ist nur so vertrauenswürdig wie ihre Rückmeldung. Nutzer müssen erkennen, ob sie gerade verbunden sind, welche Einträge noch auf Übertragung warten und ob ein Abgleich fehlgeschlagen ist. Fehlt diese Transparenz, entsteht Misstrauen, und die Mitarbeitenden schreiben vorsichtshalber wieder auf Papier mit. Ein kleines, gut sichtbares Statussymbol und eine Liste der offenen Übertragungen genügen meist.
Grenzen und Kosten
Offline-first erhöht den Aufwand in Entwicklung und Test deutlich. Es gibt mehr Zustände, mehr Randfälle und mehr Wege, auf denen Daten auseinanderlaufen können. Getestet werden muss nicht nur der Normalbetrieb, sondern auch Verbindungsabbrüche mitten in der Übertragung, lange Offline-Phasen und Updates der Anwendung, während noch Daten in der Warteschlange liegen. Zudem dürfen Browser lokalen Speicher unter bestimmten Bedingungen löschen; eine Anwendung muss deshalb darauf drängen, Daten zeitnah zu übertragen.
Datenschutz auf dem Gerät
Wer Daten offline verfügbar macht, legt sie auf Geräte, die verloren gehen oder mehreren Personen zugänglich sein können. Für Personendaten gehören deshalb eine kurze lokale Aufbewahrung, das Entfernen beim Abmelden und bei sensiblen Daten eine zusätzliche Verschlüsselung ins Konzept. Gerade im Gesundheitswesen oder bei Kundendaten im Aussendienst ist diese Abwägung Teil der Datenschutz-Folgenabschätzung.
Ein Beispiel: der Rapport auf der Baustelle
Ein Monteur öffnet morgens im Büro die App; sie lädt seine Aufträge des Tages auf das Gerät. Im Untergeschoss eines Neubaus hat er kein Netz. Er erfasst Arbeitsstunden, Material und drei Fotos, die Kundin unterschreibt auf dem Bildschirm. Die App speichert alles lokal, zeigt den Rapport als abgeschlossen an und markiert ihn mit «wartet auf Übertragung». Auf dem Weg zum nächsten Auftrag findet das Gerät wieder Empfang; die App sendet Rapport und Fotos, jede Übermittlung mit eigener Kennung. Bricht die Verbindung mitten im Foto-Upload ab, wird beim nächsten Versuch nur ergänzt, was fehlt, nichts doppelt angelegt. Erst wenn der Server alles bestätigt hat, verschwindet die Markierung — und das Büro sieht den Rapport, ohne ihn abtippen zu müssen.
In der Zwischenzeit hat die Disposition einen Folgetermin für denselben Auftrag eingetragen. Beim Abgleich erkennt die App, dass Monteur und Disposition unterschiedliche Felder geändert haben, und übernimmt beides. Hätten beide dasselbe Feld geändert, würde die Anwendung nach der vorher festgelegten Regel entscheiden oder den Fall zur Klärung markieren. Genau diese Abläufe werden vor dem Bau beschrieben und mit den Menschen getestet, die sie täglich nutzen.
Wann sich Offline-first lohnt
Unsere Faustregel bei Innopulse: Offline-first ist richtig, wenn die Arbeit sonst regelmässig an fehlendem Netz scheitert und die Erfassung vor Ort geschäftskritisch ist — Rapporte, Prüfprotokolle, Zustellnachweise, Pflegedokumentation. Wo Nutzer fast immer verbunden sind, reicht eine offline-tolerante Web-App, die keine Eingaben verliert. Wir legen diese Entscheidung pro Funktion fest, denn selten muss eine ganze Anwendung offline funktionieren.