Offline-Web-App für den Außendienst: Was sie leisten kann und wo die Grenzen liegen

Kurzantwort

Eine dafür gebaute Web-App kann ohne Netz starten, zuvor geladene Aufträge anzeigen und neue Einträge samt Fotos auf dem Gerät speichern, bis wieder eine Verbindung besteht ^{Quelle 1} , ^{Quelle 3} . Grenzen setzen die Übertragung im Hintergrund, der lokale Speicher, den Browser unter bestimmten Bedingungen löschen, und Besonderheiten von Safari auf iPhone und iPad ^{Quelle 4} , ^{Quelle 5} . Ob eine Web-App statt einer nativen App genügt, entscheiden Ihre Geräte, die Datenmenge und eine klare Konfliktregel.

Die wichtigsten Begriffe einfach erklärt

• Web-App: eine Anwendung, die Sie im Browser bedienen, etwa eine Auftragsliste mit Erfassungsmaske. Mehr dazu im Glossar: Web-App.
• Progressive Web App (PWA): eine Web-App, die sich wie eine installierte App verhält. Laut MDN kann sie aus einer Codebasis auf verschiedenen Geräten laufen, sich installieren lassen und offline sowie im Hintergrund arbeiten ^{Quelle 1} .
• Service Worker: ein Skript, das zwischen Web-App, Browser und Netz vermittelt und dabei Anfragen abfangen sowie Dateien der Anwendung lokal zwischenspeichern kann ^{Quelle 2} , ^{Quelle 3} . Service Worker setzen HTTPS voraus ^{Quelle 2} .
• IndexedDB: ein Speicher im Browser für größere Mengen strukturierter Daten, einschließlich Dateien ^{Quelle 1} . Dort warten offline erfasste Einträge und Fotos auf die Übertragung.

Was eine Web-App ohne Netz leisten kann

Die meisten Websites sind ohne Netzverbindung nicht nutzbar ^{Quelle 3} . Eine offlinefähige Web-App wird so gebaut, dass vier Dinge auch im Funkloch funktionieren:

1. Starten: Der Service Worker kann Seiten, Skripte, Stylesheets und Bilder in einem lokalen Cache ablegen und Anfragen daraus beantworten ^{Quelle 3} . Heruntergeladen wird er beim ersten Aufruf der App ^{Quelle 2} . Vor dem ersten Einsatz braucht das Gerät also einmal Netz.
2. Ansehen: Aufträge, Adressen und Notizen, die mit Verbindung geladen wurden, stehen lokal bereit. Festzulegen ist, welche Daten das sind und wie alt sie sein dürfen.
3. Erfassen: Maße, Checklisten und Fotos werden zuerst auf dem Gerät gespeichert und als nicht übertragen gekennzeichnet.
4. Übertragen: Mit Verbindung sendet die App die gesammelten Einträge an den Server.

Ob die App zuerst im Cache oder zuerst beim Server nachsieht, ist eine Abwägung zwischen schneller Antwort und aktuellem Inhalt ^{Quelle 3} .

Synchronisation: Warteschlange, Wiederholung und Konflikte

Eine Warteschlange mit sichtbarem Status

Jede Erfassung landet zuerst in einer lokalen Warteschlange, einer Art Postausgang. MDN erklärt das Muster an einem E-Mail-Programm, das ohne Netz geschriebene Nachrichten später überträgt ^{Quelle 5} . Jeder Eintrag braucht einen sichtbaren Zustand, etwa „nur auf dem Gerät“, „übertragen um 14:05 Uhr“ oder „Konflikt, bitte prüfen“.

Als übertragen gilt ein Eintrag erst, wenn der Server ihn bestätigt hat. Erst dann darf die App die lokale Kopie entfernen. Die Netzanzeige ist dafür kein Beleg, denn ein verbundenes WLAN heißt noch nicht, dass der Server erreichbar ist.

Erneut senden, ohne doppelte Einträge

Reißt die Verbindung mitten in der Übertragung ab, weiß die App nicht, ob der Eintrag schon gespeichert ist. Der HTTP-Standard nennt eine Anfragemethode idempotent, wenn mehrere gleiche Anfragen damit dieselbe beabsichtigte Wirkung haben wie eine einzelne; POST zählt nicht dazu. Solche Anfragen soll ein Client nicht automatisch wiederholen, außer er weiß, dass sie in der Sache idempotent sind, oder kann erkennen, dass die erste Anfrage nicht ausgeführt wurde ^{Quelle 8} .

Eine Lösung: Jeder Eintrag erhält schon auf dem Gerät eine eindeutige Kennung, die bei jedem Versuch mitgeht. Der Server erkennt die Wiederholung und bestätigt den vorhandenen Eintrag, statt einen zweiten anzulegen. Das Prinzip erklärt der Glossarbegriff Idempotenz. Wichtig ist das auch, weil eine abgebrochene Hintergrundübertragung beim nächsten Versuch von vorn beginnt ^{Quelle 3} .

Konflikte mit Versionsnummern lösen

Ein Konflikt entsteht, wenn derselbe Datensatz unterwegs und im Büro geändert wurde. „Der letzte gewinnt“ ist einfach, überschreibt aber unbemerkt die andere Änderung. Nachvollziehbarer ist eine Versionsnummer: Die App sendet mit jeder Änderung die Version, auf der sie beruht. Ist der Datensatz auf dem Server inzwischen neuer, lehnt der Server ab, und die App zeigt beide Fassungen zur Entscheidung.

HTTP sieht dafür bedingte Anfragen vor. Mit dem Kopffeld If-Match soll verhindert werden, dass parallele Änderungen einander versehentlich überschreiben. Entspricht der Datensatz nicht mehr dem erwarteten Stand, darf der Server die Änderung nicht ausführen und kann mit dem Status 412 antworten ^{Quelle 8} .

Nicht jede Datenart braucht eine menschliche Entscheidung: Fotos lassen sich etwa ergänzen statt ersetzen. Legen Sie die Regel je Datenart vorab fest.

Die Grenzen, genau betrachtet

Speicherplatz und Löschung durch den Browser

Wie viel eine Website speichern darf, legt jeder Browser selbst fest ^{Quelle 4} . Standardmäßig gelten Daten als „best-effort“: Sie bleiben, solange die Quote eingehalten ist, das Gerät genug Platz hat und niemand sie in den Browsereinstellungen löscht. Wird der Speicher knapp, löschen Browser zuerst die Daten der am längsten nicht genutzten Websites, jeweils alle Daten einer Website zugleich ^{Quelle 4} .

Safari kann Daten auch ohne Speichermangel entfernen: Ist der Schutz vor websiteübergreifendem Tracking aktiv und gab es in den letzten sieben Tagen der Browsernutzung keine Interaktion wie Klicken oder Tippen mit der Website, löscht Safari die per Skript angelegten Daten ^{Quelle 4} . Einträge sollten also zeitnah übertragen werden.

Die Quote ist zudem nur eine Obergrenze: Laut WebKit gibt es keine Gewähr, diese Menge tatsächlich speichern zu können, und Speicherfehler müssen abgefangen werden ^{Quelle 6} . Mit navigator.storage.estimate() kann die App die geschätzte Belegung abfragen und bei vielen Fotos rechtzeitig warnen ^{Quelle 4} .

Dauerhafte Speicherung anfragen

Mit navigator.storage.persist() kann eine Web-App dauerhafte Speicherung anfragen. So gespeicherte Daten löscht der Browser nur, wenn die Nutzerin oder der Nutzer es in den Einstellungen veranlasst ^{Quelle 4} . Eine Zusage ist die Anfrage nicht: Firefox fragt nach, Safari und die meisten Chromium-Browser entscheiden ohne Rückfrage anhand der bisherigen Nutzung ^{Quelle 4} . WebKit nennt als ein Kriterium, ob die Website als Web-App vom Home-Bildschirm geöffnet wird ^{Quelle 6} .

Übertragung im Hintergrund

Die Background Synchronization API lässt einen Service Worker Aufgaben ausführen, sobald eine stabile Verbindung besteht ^{Quelle 5} . Laut den Kompatibilitätsdaten von MDN (abgerufen am 17.09.2026) unterstützen Chrome, Edge und Chrome für Android sie, Firefox und Safari nicht, auch nicht Safari auf iPhone und iPad ^{Quelle 5} . Auch wo sie vorhanden ist, lässt sich die Anfrage nur bei geöffneter App stellen, Browser begrenzen Wiederholungen und Dauer, und inaktive Service Worker werden gestoppt ^{Quelle 3} .

Planen Sie die Übertragung deshalb auch ohne diese Schnittstelle: beim Öffnen der App, bei wiederhergestellter Verbindung während der Nutzung und auf Knopfdruck.

Besonderheiten auf iPhone und iPad

• Browser-Engine: Browser anderer Anbieter mussten dort bisher WebKit verwenden, die Engine von Safari; dann gelten für sie dieselben Speicherregeln. In der EU erlaubt Apple seit iOS 17.4 alternative Engines mit eigenen Regeln ^{Quelle 4} . Testen Sie jeden eingesetzten Browser.
• Mitteilungen: Web Push gibt es seit iOS und iPadOS 16.4 für Web-Apps, die auf dem Home-Bildschirm abgelegt wurden. Die Erlaubnis darf die App nur nach einer direkten Aktion anfragen, etwa dem Tippen auf eine Schaltfläche ^{Quelle 7} .
• Stand: Die zitierten WebKit-Beiträge sind von 2023; prüfen Sie das Verhalten auf Ihren Systemversionen.

Sicherheit und Geräteverlust

Was offline verfügbar ist, liegt auf dem Gerät. Daraus folgt:

• Nur das Nötige offline halten, etwa die Aufträge der Woche statt des ganzen Kundenstamms.
• Rechte auf dem Server prüfen: Der Server prüft bei jeder Übertragung, ob das Konto den Datensatz ändern darf. Wie sich Zugriffe festlegen lassen, erklärt der Glossarbegriff Rollen und Berechtigungen.
• Beim Abmelden aufräumen: Die App entfernt die lokalen Daten und warnt vorher, falls noch Einträge ausstehen.
• Geräteverlust einplanen: Die Anmeldung eines verlorenen Geräts wird serverseitig gesperrt. Daten auf dem Gerät schützt das nicht, dafür braucht es Bildschirmsperre und Geräteverwaltung.
• Nicht im privaten Modus arbeiten: Dort löschen Browser gespeicherte Daten in der Regel, wenn der Modus endet ^{Quelle 4} .

Web-App oder native App?

Keine Variante ist grundsätzlich besser. Eine Web-App passt, wenn die benötigten Funktionen auf Ihren Geräten verfügbar sind und die Offline-Daten überschaubar bleiben. Fehlen dort wichtige Funktionen, lohnt die Prüfung einer nativen App.

Beispiel: Aufmaß im Keller ohne Empfang

Das Beispiel ist frei erfunden. Ein Heizungsbauer nimmt im Keller eines Mehrfamilienhauses das Aufmaß für einen Kesseltausch auf, sein Tablet hat dort keinen Empfang.

1. Vorbereitung: Morgens lädt die Web-App im Betrieb die Aufträge des Tages, darunter die Objektnotiz in Version 3.
2. Erfassung: Im Keller erfasst der Monteur Raummaße und Anschlüsse und macht sechs Fotos. Die App zeigt „3 Einträge und 6 Fotos nur auf dem Gerät“.
3. Zwei Änderungen: Er ergänzt die Objektnotiz um den Ort des Kellerschlüssels. Gleichzeitig trägt das Büro dort eine neue Telefonnummer ein, auf dem Server entsteht Version 4.
4. Übertragung: Am Fahrzeug hat das Tablet wieder Netz. Beim vierten Foto reißt die Verbindung ab; beim nächsten Versuch erkennt der Server die Kennung und speichert das Foto nur einmal.
5. Konflikt: Der Server lehnt die Notiz des Monteurs ab, weil sie auf Version 3 beruht. Die App zeigt beide Fassungen, er führt sie zusammen, daraus wird Version 5.
6. Abschluss: Die App meldet „Alles übertragen“ und entfernt erst dann die lokalen Kopien.

Prüfliste vor der Entwicklung

• Welche Abläufe müssen ohne Netz funktionieren: ansehen, erfassen oder ändern?
• Welche Daten liegen offline auf dem Gerät, welche ausdrücklich nicht?
• Wie lange dürfen Einträge auf dem Gerät warten, und wie viele Fotos entstehen je Einsatz?
• Welche Geräte, Systemversionen und Browser nutzt Ihr Team, und startet die App im Browser oder vom Home-Bildschirm?
• Welche Konfliktregel gilt je Datenart, und wer entscheidet im Zweifel?
• Wer erfährt von Einträgen, die dauerhaft nicht übertragen werden?
• Welche Programme erhalten die Daten danach, etwa über eine API-Integration?
• Was passiert bei Abmeldung, Gerätewechsel und Geräteverlust?
• Wie wird getestet: im Flugmodus, bei schwachem Netz, mit Abbruch mitten in der Übertragung, mit fast vollem Speicher und auf jedem Gerätetyp?

Ein abgegrenzter erster Ablauf, etwa nur das Aufmaß, zeigt früh, ob das Konzept im Alltag trägt. Wie sich ein solcher Umfang zuschneiden lässt, erklärt der Glossarbegriff MVP.

Typische Fehler

• Nur die Oberfläche offline geplant: Die App startet im Funkloch, aber das Speichern scheitert.
• „Der letzte gewinnt“ ohne Hinweis: Änderungen aus dem Büro gehen unbemerkt verloren.
• Wiederholung ohne Kennung: Nach einem Verbindungsabbruch entstehen doppelte Einträge.
• Auf Background Sync verlassen: Safari bietet die Schnittstelle nicht an ^{Quelle 5} . Einträge bleiben liegen, bis jemand die App öffnet.
• Speicherfehler nicht abgefangen: Bei vollem Speicher wird ein Foto ohne verständliche Meldung nicht gesichert ^{Quelle 6} .
• Updates übersehen: Geräte laufen noch mit der alten Version ^{Quelle 2} , der Server erwartet aber schon ein neues Datenformat.
• Nur im Büro-WLAN getestet: Probleme bei schwachem Netz zeigen sich erst beim Kunden.

Wenn Sie Unterstützung möchten

Ob eine Offline-Web-App zu Ihrem Außendienst passt, lässt sich mit der Prüfliste vor der Entwicklung klären. Wie wir interne Werkzeuge mit Ihnen planen und abstimmen, beschreibt die Seite Interne Tools und Dashboards, einen Überblick gibt die Seite Web-Anwendungen. Wenn Sie noch abwägen, ob Sie überhaupt ein eigenes Werkzeug brauchen, hilft der Ratgeber Excel oder interne Web-App.