Offline-App: wenn das Netz fehlt

Ein Keller, der inspiziert werden muss, eine Tiefgarage, eine Baustelle auf dem Land, ein Lager mit dicken Wänden: Der Einsatzort ist oft dort, wo das Netz nicht hinreicht. Eine App, die in diesem Moment eine Fehlermeldung anzeigt, hat verloren. Der Techniker notiert auf einem Block, fotografiert mit der Kamera des Smartphones, und alles geht wieder den Weg, den die App abschaffen sollte: abendliches Abtippen, verlorene Fotos, Informationen, die einen Tag zu spät ankommen.

Offline ist kein Häkchen in einem Angebot. Es ist eine Folge von Entscheidungen, von der einfachsten bis zur teuersten, die man besser in voller Kenntnis trifft.

Kurz gesagt

• Offline hat drei Stufen: Die App öffnet sich, bereits angesehene Daten bleiben einsehbar, Eingaben warten auf die Rückkehr des Netzes.
• Die dritte Stufe ist im Außendienst die nützlichste und die teuerste, weil sich alles bei der Synchronisierung entscheidet.
• Zwei Personen, die offline denselben Datensatz ändern, werfen eine fachliche Frage auf, nicht nur eine technische: Wer hat recht?
• Eine aus dem Browser installierbare App deckt die ersten beiden Stufen ab; die dritte ist in einer nativen App robuster.
• Die Entscheidung fällt auf Grundlage einer Bestandsaufnahme: Wo verlieren Ihre Teams das Netz, und wie lange?

Die drei Stufen des Offline-Betriebs

Zu sagen, dass eine App „offline funktioniert“, kann drei sehr verschiedene Dinge bedeuten.

1. 01Sie öffnet sich.

   Die Bildschirme sind auf dem Smartphone gespeichert: Die App startet ohne Netz, statt eine leere Seite anzuzeigen. Ihre Daten dagegen brauchen eine Verbindung, um sich zu aktualisieren.

2. 02Sie lässt sich einsehen.

   Bereits geöffnete Vorgänge (der Kundendatensatz, der Plan, die Liste der heutigen Einsätze) bleiben lesbar, mit dem Datum ihrer letzten Aktualisierung.

3. 03Sie speichert.

   Eingaben, angekreuzte Felder und Fotos werden auf dem Smartphone gespeichert und bei Rückkehr des Netzes an den Server gesendet, ohne etwas zu verlieren oder doppelt zu senden.

Jede Stufe baut auf der vorherigen auf, und jede bringt zusätzliche Arbeit. Die erste ist fast eine Einstellung. Die zweite verlangt zu entscheiden, was das Smartphone speichert und wie lange. Die dritte verändert die Architektur der App.

Was Offline für das Team ändert

Der Nutzen misst sich nicht in Funktionen, sondern in Handgriffen, die das Team nicht mehr machen muss.

• Vor Ort erfassen, ein einziges Mal. Der Befund wird vor der Anlage aufgenommen, nicht aus dem Gedächtnis auf dem Rückweg zum Wagen. Die Details, die man in zwanzig Minuten vergisst, bleiben im Vorgang.
• Kein doppelter Ablauf mehr. Ohne Offline behält das Team den Block „für alle Fälle“, und das Abtippen kommt zurück. Mit Offline verschwindet der Block wirklich.
• Ein datierter Nachweis. Foto und Uhrzeit des Einsatzes werden dem Vorgang in dem Moment zugeordnet, in dem sie entstehen, und nicht, wenn das Netz zurückkommt.
• Weniger Warten. Niemand sucht mehr nach einem Netzbalken, das Smartphone in die Luft gehalten, bevor er zur nächsten Aufgabe übergehen kann.

Diese Gewinne setzen voraus, dass die App bereits angenommen wird: Die Bedingungen dafür, kurze Bildschirme und reibungslose Anmeldung, sind in was eine Außendienst-App für Ihre Teams ändert beschrieben.

Das eigentliche Thema: die Synchronisierung

Auf dem Smartphone zu speichern ist der einfache Teil. Die Arbeit steckt in der Rückkehr des Netzes.

Drei Fragen entscheiden über die Qualität dieses Wegs.

Nichts doppelt senden. Eine unterbrochene Sendung wird erneut versucht. Wenn jede Eingabe eine auf dem Smartphone erzeugte eindeutige Kennung trägt, erkennt der Server eine bereits erhaltene Sendung und legt kein Duplikat an.

Der Uhr des Smartphones nicht vertrauen. Sie lässt sich von Hand einstellen. Die Uhrzeit der Eingabe kann vom Smartphone zur Information notiert werden, aber was zählt (der Tag eines Einsatzes, eine Frist), wird auf dem Server validiert, wie wir in der Sicherheit einer App erklären.

Wissen, wer recht hat. Zwei Techniker ändern denselben Datensatz, jeder in einem anderen Keller. Der erste, der wieder Netz hat, sendet seine Version; überschreibt der zweite die erste? Firestore, die Datenbank von Google für Apps, schreibt es in seiner Dokumentation zum Offline-Betrieb klar: Bei mehreren Änderungen desselben Dokuments gewinnt der letzte Schreibvorgang.

Installierbare Web-App oder App aus den Stores

Die Wahl zwischen einer installierbaren Web-App und einer nativen App, verglichen in PWA oder native App, bekommt eine besondere Färbung, wenn das Netz fehlt.

Die Grenzen des Webs sind dokumentiert. WebKit, die Engine von Safari, beschreibt in seiner Speicherrichtlinie von 2023 eine automatische Löschung der Daten einer Website, wenn das Kontingent überschritten ist, wenn das Gerät wenig Speicher hat oder wenn die Website eine Weile nicht genutzt wurde. Die Schnittstelle, mit der eine Web-App eine Sendung bis zur Rückkehr des Netzes aufschieben kann, ist laut der Dokumentation von MDN in mehreren der meistgenutzten Browser nicht verfügbar. Und im Web ist die Offline-Persistenz von Firestore standardmäßig deaktiviert, mit einem Rat: den Nutzer zu fragen, ob er auf einem vertrauenswürdigen Gerät ist, bevor sensible Daten gespeichert werden.

Auf nativer Seite verfügt eine mit Expo gebaute App über eine SQLite-Datenbank auf dem Smartphone, die über Neustarts hinweg erhalten bleibt. Auch die Wahl des Back-Ends zählt: Firestore sieht Offline auf Android und iPhone standardmäßig vor, während eine Postgres-Datenbank wie die von Supabase verlangt, die Synchronisierung selbst zu organisieren, wie Supabase, Firebase oder eigener Server ausführt.

Für ein internes Werkzeug, das sich vor allem ohne Netz öffnen und einsehen lassen muss, genügt die installierbare App oft. Wenn wichtige Eingaben einen Tag ohne Netz überstehen müssen, ist die native App sicherer.

Was es kostet und wann man darauf verzichten kann

Vollständiger Offline-Betrieb ist eine der Entscheidungen, die den Preis einer App am stärksten verändern: Er betrifft jeden Eingabebildschirm, erfordert zusätzliche Tests (das Netz mitten in einer Sendung kappen, zwei Smartphones am selben Datensatz) und muss mit jeder Version gepflegt werden, wie der Rest des Wartungsbudgets.

Man kann darauf verzichten, wenn die Ausfälle kurz und selten sind, wenn die Eingabe ein paar Minuten warten kann oder wenn die App vor allem zum Nachschlagen dient. Man kann nicht darauf verzichten, wenn das Team Stunden ohne Netz verbringt oder wenn eine verlorene Eingabe echte Kosten verursacht: ein anfechtbarer Befund, eine nicht nachgewiesene Lieferung, ein erneut berechneter Einsatz.

Womit Sie beginnen

1. 01Die Funklöcher erfassen.

   Zwei Wochen lang notiert das Team, wo das Netz fehlt und wie lange.

2. 02Die Handgriffe einordnen.

   Welche ohne Netz erfolgen müssen (einen Befund erfassen, ein Foto machen), welche warten können (die vollständige Historie einsehen).

3. 03Die Konfliktregeln festschreiben.

   Für jede von mehreren änderbare Angabe: Wer gewinnt.

4. 04Ohne Netz testen.

   An einer ersten Version, im Flugmodus, mit den Personen, die sie nutzen werden.

Diese Entscheidungen werden in das Lastenheft der App geschrieben und früh an einem klickbaren Prototyp getestet. Die übrigen Entscheidungen eines Projekts haben jeweils ihren eigenen Artikel: Individuallösung oder Standardwerkzeug, unter dem eigenen Entwicklerkonto veröffentlichen, Benachrichtigungen, das Abonnement, das Kundenportal, KI in einer App, die Übernahme einer aufgegebenen App, Low-Code und Vibe Coding.

Unsere App-Entwicklung beginnt mit einer schriftlichen Rahmung: was die App am ersten Tag kann, mit oder ohne Netz.

Häufige Fragen

Quellen

1. Firebase-Dokumentation, Offline-Datenzugriff (neuer Tab)firebase.google.com
2. WebKit, Aktualisierung der Speicherrichtlinie, August 2023 (neuer Tab)webkit.org
3. MDN, Background Synchronization API (neuer Tab)developer.mozilla.org
4. Expo-Dokumentation, SQLite (neuer Tab)docs.expo.dev