Offline Modus in Apps: So planen Sie eine App, die ohne Internet funktioniert

In diesem Leitfaden gehen Talha Aslan und Team die Entscheidung für einen Offline Modus Schritt für Schritt durch. Wir schreiben bewusst keinen allgemeinen Überblick über App Entwicklung. Stattdessen beantworten wir eine einzige Frage: Was soll Ihre App tun, wenn das Netz weg ist? Deshalb endet jeder Abschnitt mit einer Checkliste, einer Entscheidung oder nummerierten Schritten. Code zeigen wir nicht. Produktverantwortliche, Design und Entwicklung sollen dieselbe Architektur am selben Tisch besprechen können.

Welche Apps müssen ohne Internet funktionieren?

Nicht jede App braucht Offline Unterstützung. Andererseits verlieren manche Geschäftsmodelle bei jedem Funkloch echte Arbeit. In folgenden Fällen ist der Offline Modus kein Extra, sondern das Produkt selbst:

• Außendienst: Servicetechniker, Vertrieb, Zählerableser und Prüfer, die in Kellern, auf Baustellen oder auf dem Land arbeiten.
• Lager und Bestand: Barcode Scans, Inventur und Versandbestätigung in Gängen mit schwachem Empfang.
• Zustellung und Logistik: Zustellnachweis, Fotos und Notizen unterwegs.
• Lern- und Inhaltsapps: Lektionen und Medien im Flugzeug, im Zug oder bei knappem Datenvolumen.
• Formulare und Datenerfassung: Einlasskontrolle bei Veranstaltungen, Umfragen und Prüfprotokolle vor Ort.

Allerdings brauchen Überweisungen, Sofortzahlungen oder eine Platzbuchung in Echtzeit eine Bestätigung vom Server. Das heißt, Offline Unterstützung ist keine Ja oder Nein Frage für die ganze App. Sie entscheiden sie pro Aktion. Sobald Ihr Team festlegt, welche Aktionen offline laufen dürfen, werden spätere Diskussionen im Projekt deutlich kürzer.

Worin unterscheidet sich Offline First von einer reinen Online App?

Viele Apps entstehen online zuerst. Fällt die Verbindung aus, erscheint eine Fehlermeldung. Eine Offline First App dreht diese Sicht um. Die Android Entwicklerdokumentation zum Aufbau einer Offline First App beschreibt sie als App, die alle oder einen kritischen Teil ihrer Kernfunktionen ohne Internetzugang erledigen kann. Zudem empfiehlt sie, lokale Daten sofort anzuzeigen, statt auf den ersten Netzwerkaufruf zu warten.

Konkret sieht der Unterschied so aus. In einer Online App öffnet die Person einen Bildschirm, die App fragt den Server, und die Liste füllt sich erst mit der Antwort. In einer Offline First App füllt sich der Bildschirm sofort aus der lokalen Datenbank. Gleichzeitig holt die App im Hintergrund frische Daten und schreibt sie zuerst in die lokale Datenbank. Somit liest der Bildschirm immer aus einer einzigen Quelle. Kurz gesagt: Niemand wartet, die Daten aktualisieren sich leise. Der Preis dafür ist, dass Sie Synchronisierung und Konfliktregeln von Anfang an durchdenken müssen.

Welche Daten gehören für den Offline Modus aufs Gerät?

Alles herunterzuladen belastet Speicher, Akku und Datensicherheit. Daher beginnen Sie mit einer Dateninventur. Diese Checkliste beschleunigt sie:

1. Welche Datensätze braucht die Person für ihre tägliche Arbeit? Zum Beispiel die Aufträge des Tages.
2. Welche Stammdaten ändern sich selten? Typisch sind Produktkatalog, Preisliste und Kundenadressen.
3. Was entsteht offline? Formulare, Fotos, Unterschriften und Notizen.
4. Sind sensible Daten dabei? Personenbezogene Daten brauchen verschlüsselte Speicherung und eine Löschregel beim Abmelden.
5. Wie viel Verlauf reicht? Die letzten dreißig Tage oder nur offene Aufträge?

Wenn Sie diese Liste ausfüllen, landen die meisten Projekte bei drei Gruppen: Daten, die lokal sein müssen, Daten, die Sie bei Gelegenheit zwischenspeichern, und Daten, die nur online bleiben. Außerdem bestimmt diese Aufteilung, wie viel die App beim ersten Start lädt. Die Serverseite des Themas beschreiben wir in unserem Beitrag Caching erklärt.

Cache oder lokale Datenbank: Was brauchen Sie wirklich?

Das Wort Cache steht oft für zwei verschiedene Dinge. Erstens gibt es den temporären Cache. Sie behalten die letzte Antwort, damit ein Bildschirm schneller öffnet, und ein Verlust schadet nicht. Zweitens gibt es die dauerhafte lokale Datenbank. Dort liegen die Daten, die Personen offline erfassen, und ein Verlust ist nicht akzeptabel. Deshalb lautet die erste Frage: Was passiert, wenn diese Daten verschwinden?

Laut Android Leitfaden soll die lokale Datenquelle die maßgebliche Wahrheit sein und die einzige Stelle, aus der höhere Schichten lesen. Eine relationale Datenbank passt zu strukturierten Datensätzen, ein Schlüsselwertspeicher zu einfachen Einstellungen und das Dateisystem zu großen Medien. Auch iOS bietet vergleichbare dauerhafte Speicheroptionen; die Wahl hängt von Ihrem Technologiestack ab. Wichtiger als der Name der Technik ist die Regel: Eingaben landen immer zuerst im dauerhaften Speicher, das Netz kommt danach.

Welche Schreibstrategie passt zu welcher Aktion im Offline Modus?

Der Android Leitfaden beschreibt drei Schreibstrategien für Offline First Apps. Sie wählen eine pro Aktion, denn keine Strategie passt für die ganze App. Diese Entscheidungstabelle hilft bei der Wahl:

Die meisten Außendienst- und Lagerapps nutzen die dritte Strategie, weil keine Eingabe verloren gehen darf. Allerdings bringt diese Strategie Konfliktrisiken mit sich. Deshalb sollten Sie den Abschnitt zu Konflikten weiter unten nicht überspringen.

Wie soll die Synchronisierung nach dem Funkloch ablaufen?

Synchronisierung heißt, lokale Daten mit den Serverdaten abzugleichen. Die Android Dokumentation nennt zwei Hauptansätze: Pull und Push. Beim Pull Ansatz holt die App die Daten eines Bildschirms kurz bevor sie ihn zeigt. Das ist zunächst einfach umzusetzen. Allerdings findet eine Person nach einem langen Ausfall auf einem nie besuchten Bildschirm leere oder veraltete Daten.

Beim Push Ansatz lädt die App beim ersten Start einen Grundbestand. Danach meldet der Server Änderungen, und die App holt nur die geänderten Datensätze. Dieser Ansatz passt zu Apps, die lange offline bleiben. Dafür braucht er einen Server, der Synchronisierung unterstützt, und versionierte Daten. Deshalb kombinieren viele Teams beides. Zum Beispiel erhält eine Außendienstapp die Aufträge morgens per Push, während der Produktkatalog erst beim Öffnen eines Bildschirms nachlädt.

Fehlgeschlagene Anfragen in kurzer Folge zu wiederholen, leert den Akku und belastet den Server. Stattdessen empfiehlt die Dokumentation einen exponentiellen Backoff, also wachsende Wartezeiten zwischen den Versuchen. Zudem sollten Sie eine nicht autorisierte Anfrage erst nach erneuter Anmeldung wiederholen.

Was ist ein Synchronisierungskonflikt und wie lösen Sie ihn?

Ein Konflikt entsteht, wenn zwei Stellen denselben Datensatz ändern, ohne voneinander zu wissen. Ein Beispielszenario: Die Lagerleitung erfasst auf dem Tablet einen Bestand von 40, während im Büro jemand denselben Datensatz auf 38 korrigiert. Wenn das Tablet wieder online ist, welcher Wert gilt? Wenn Sie das nicht zu Projektbeginn klären, entscheidet eine zufällige Codezeile.

Der Android Leitfaden nennt „der letzte Schreibvorgang gewinnt“ als verbreiteten Ansatz für mobile Apps. Jedes Gerät hängt einen Zeitstempel an, und der Server behält den neueren Wert. Das ist einfach, passt aber nicht zu jedem Datentyp. Prüfen Sie daher diese Optionen je Datentyp:

• Letzter Schreibvorgang gewinnt: Einstellungen und Statusfelder, die eine Person ändert.
• Zusammenführen auf Feldebene: Ändert eine Person die Telefonnummer und eine andere die Adresse, bleiben beide Änderungen erhalten.
• Bewegungen statt Endwerte: Bestand als Zugang und Abgang speichern, damit keine Bewegung verloren geht.
• Nachfragen: Bei Datensätzen mit rechtlicher oder finanzieller Wirkung beide Versionen zeigen und eine Person wählen lassen.
• Serverregel: Ergänzt jemand offline einen bereits abgeschlossenen Auftrag, lehnt der Server ab und nennt den Grund.

Wie bauen Sie das Datenmodell, um Konflikte zu vermeiden?

Konflikte zu lösen, kostet mehr, als sie zu vermeiden. Also richten Sie das Datenmodell von Anfang an auf Offline Nutzung aus. Erstens bekommt jeder Datensatz eine eindeutige Kennung, die das Gerät selbst erzeugt. Wenn Sie auf Kennungen vom Server warten, lassen sich offline erstellte Datensätze kaum verknüpfen. Zweitens erhält jeder Datensatz eine Versionsnummer oder einen Änderungszeitpunkt. Drittens nutzen Sie eine Löschmarkierung, statt Zeilen tatsächlich zu entfernen. Sonst erfahren andere Geräte nie von der Löschung.

Dann gibt es das Problem doppelter Anfragen. Bricht die Verbindung genau beim Eintreffen der Antwort ab, weiß das Gerät nicht, ob die Anfrage ankam, und sendet sie erneut. Speichert der Server sie zweimal, entsteht eine doppelte Zustellung oder ein doppelter Lagerabgang. Die Lösung ist ein Vorgangsschlüssel pro Aktion, den der Server kein zweites Mal verarbeitet. Dieses Prinzip erklären wir im Beitrag Was ist Idempotenz; für die Offline Synchronisierung ist es fast Pflicht. Die Grundlagen der Schnittstelle zwischen App und Server finden Sie unter Was ist eine API.

Was sollten Sie vor einem Projekt mit Offline Modus festlegen?

Inzwischen ist klar: Der Offline Modus ist keine Bildschirmfunktion, sondern die Datenarchitektur Ihrer App. In der Praxis haben Teams die größten Probleme, wenn sie ihn erst nach dem Start nachrüsten. Eine Online App nachträglich offlinefähig zu machen, bedeutet oft, die Datenschicht neu zu schreiben. Daher beantworten Sie vor dem Start schriftlich vier Fragen. Welche Aktionen laufen offline? Wie lange kann eine Person offline bleiben? Welche Daten liegen auf dem Gerät? Wer gewinnt im Konfliktfall?

Diese Fragen beantwortet Ihr Geschäftsprozess, nicht die Technik. Fehlt Ihrem Team die Erfahrung mit mobiler Architektur, beginnt unsere App Entwicklung genau mit diesem Rahmen, den wir gemeinsam mit Ihnen erarbeiten. So geht die erste Version mit einer soliden Datenschicht live, und das Risiko einer späteren Neuentwicklung sinkt. Wenn Sie über einen plattformübergreifenden Stack nachdenken, beschreibt unser Beitrag Was ist React Native die Vor- und Nachteile einer gemeinsamen Codebasis.

Wie zeigen Sie Verbindung und Synchronisierungsstatus an?

Die Oberfläche ist der am häufigsten vernachlässigte Teil. Wissen Personen nicht, ob ihre Daten angekommen sind, erledigen sie die Arbeit doppelt oder verlieren das Vertrauen in die App. Deshalb brauchen Sie für jeden Datensatz eine klare Statussprache. Wir empfehlen diesen Grundsatz:

1. Auf dem Gerät gespeichert: Die Daten liegen im dauerhaften Speicher, aber noch nicht auf dem Server.
2. Wird gesendet: Die Synchronisierung läuft.
3. Synchronisiert: Der Server hat den Datensatz bestätigt.
4. Aktion nötig: Die Person muss handeln, und die Meldung nennt Grund und Lösung.

Zusätzlich platzieren Sie oben im Bildschirm eine allgemeine Verbindungsanzeige, aber keinen dauerhaften Fehlerkasten. Wenn Personen offline weiterarbeiten können, sollte die Meldung ruhig klingen: „Sie sind offline. Ihre Eingaben bleiben auf diesem Gerät.“ Schließlich zeigen Sie den Zeitpunkt der letzten Aktualisierung. Das zählt vor allem bei Daten, die veralten, etwa Preise oder Bestände. Für kurze Statusmeldungen hilft unser Beitrag Toast Benachrichtigungen gestalten.

Welche Knöpfe sollten im Offline Modus deaktiviert sein?

Die Regel ist einfach: Verstecken Sie keine Aktion, die eine Verbindung braucht. Deaktivieren Sie sie und erklären Sie den Grund. Verstecken verwirrt nur, denn der Knopf von gestern ist heute plötzlich weg. Ein deaktivierter Knopf mit kurzem Hinweis ist klar und barrierefrei. Allerdings müssen auch Menschen mit Screenreader diesen Hinweis hören. Diesen Teil behandelt unser Schwesterbeitrag App Barrierefreiheit mit VoiceOver und TalkBack testen.

Zum Beispiel kann eine Außendienstapp einen Auftrag offline abschließen, aber eine Rechnung per E-Mail nur mit Server versenden. Dann bleibt der Rechnungsknopf deaktiviert, mit einem Hinweis wie „Rechnungsversand braucht eine Verbindung. Der Auftragsabschluss liegt sicher auf diesem Gerät.“ Somit weiß die Person, was sie jetzt tun kann und worauf sie wartet.

Wie gehen Sie offline mit Fotos, Unterschriften und großen Dateien um?

In Außendienstapps liegt das Gewicht bei Medien, nicht bei Text. Ein Zustellfoto ist zum Beispiel weit größer als ein Textdatensatz. Deshalb bekommen Medien eine eigene Warteschlange. Senden Sie zuerst den Textteil, danach die Dateien einzeln. So erreicht der Auftrag den Server selbst bei schwacher Verbindung.

Dann gilt diese Checkliste. Komprimieren Sie Dateien auf dem Gerät. Wählen Sie ein Uploadverfahren, das nach einer Unterbrechung fortsetzt. Löschen Sie keine Datei vom Gerät, bevor der Server sie bestätigt. Warnen Sie die Person, bevor der Speicher voll ist. Der Android Leitfaden erwähnt zudem, dass verwaltete Clouddienste Uploads bei Netzabbrüchen pausieren und fortsetzen können. Ob Sie einen verwalteten Dienst nutzen oder einen eigenen Stack bauen, hängt davon ab, wie viel Kontrolle Sie brauchen.

Wie funktioniert der Offline Modus in einer Außendienstapp?

Gehen wir ein Beispielszenario durch. Ein Servicetechniker öffnet morgens im Büro die App. Sie lädt die Aufträge des Tages, die Kundenadressen und die Ersatzteilliste. Dann fährt der Techniker zur ersten Adresse, und im Keller gibt es keinen Empfang. Trotzdem öffnet er den Auftrag, hakt die Arbeiten ab, wählt die verbrauchten Teile, macht zwei Fotos und lässt die Kundin auf dem Bildschirm unterschreiben.

Die App schreibt diesen Datensatz in die lokale Datenbank und markiert ihn als „auf dem Gerät gespeichert“. Zurück im Wagen verbindet sich das Telefon. Zuerst geht der Auftragstext hoch, danach Fotos und Unterschrift. Wenige Minuten später sieht die Disposition den Auftrag als erledigt. Zu keinem Zeitpunkt sieht der Techniker eine Meldung „kein Internet“. Storniert das Büro am selben Tag einen Auftrag, übernimmt die App diese Änderung bei der nächsten Synchronisierung und informiert den Techniker mit einem schlichten Hinweis.

Wenn Sie dieses Szenario vor der Entwicklung aufschreiben, zeigen sich fehlende Entscheidungen. Was passiert etwa, wenn der Techniker einen stornierten Auftrag schon begonnen hat? Die Antwort ist eine Geschäftsregel, und die müssen Sie festlegen.

Wie sollte der Offline Modus in einer Lagerapp aufgebaut sein?

Im Lager ist die Lage anders. Mehrere Personen berühren denselben Artikel gleichzeitig, also ist das Konfliktrisiko höher als im Außendienst. Deshalb empfehlen wir, jeden Scan als Bewegung zu speichern, statt den Bestand als Endwert zu senden. Scannt jemand zehn Stück, legt das Gerät die Bewegung „zehn Stück Zugang“ in die Warteschlange. Der Server summiert alle Bewegungen und berechnet den aktuellen Bestand.

Somit geht keine Bewegung verloren, wenn zwei Personen dasselbe Regal auf verschiedenen Tablets zählen. Außerdem kann der Server ein unmögliches Ergebnis wie einen negativen Bestand ablehnen und eine Prüfaufgabe für die Leitung anlegen. Außerdem zählt die Scangeschwindigkeit. Statt auf das Netz zu warten, zeigen Sie das Ergebnis sofort aus dem lokalen Produktkatalog. Kurz gesagt schützt der Offline Modus in einer Lagerapp sowohl Tempo als auch Datenqualität.

Unterscheidet sich der Offline Modus auf iOS und Android?

Die Architekturregeln sind auf beiden Plattformen gleich. Lokale Daten sind die Wahrheit, Schreibvorgänge kommen in eine Warteschlange, und die Synchronisierung startet mit der Verbindung. Allerdings unterscheiden sich die Regeln für Hintergrundarbeit. Für Android beschreibt die WorkManager Dokumentation dauerhafte Aufgaben mit Netzbedingung und Wiederholung, die das System auch bei geschlossener App einplanen kann. Unter iOS verwaltet das System die Hintergrundzeit strenger. Sie sollten nicht annehmen, dass Ihre App genau dann aufwacht, wann Sie es möchten.

Dieser Unterschied prägt also das Design. Zum Beispiel sollte die App für eine Person mit iPhone bei jedem Öffnen die Warteschlange prüfen und offene Datensätze sofort senden. Zudem können Energiesparmodi auf beiden Plattformen Hintergrundarbeit verzögern. Daher macht eine Anzeige der letzten Synchronisierung den Plattformunterschied für Personen unsichtbar. Auch mit einem plattformübergreifenden Framework testen Sie dieses Verhalten auf beiden Geräten getrennt. Anders gesagt: Die Codebasis kann gemeinsam sein, der Testplan nicht.

Wie testen Sie den Offline Modus?

Den Flugmodus ein und auszuschalten, reicht nicht. Echte Ausfälle sind unordentlicher: Die Verbindung besteht, ist aber extrem langsam, die Anfrage geht raus, aber keine Antwort kommt zurück, oder das Gerät schaltet mitten im Speichern ab. Nehmen Sie deshalb diese Szenarien in Ihren Testplan auf:

1. Öffnen Sie die App komplett offline und erledigen Sie den Kernablauf von Anfang bis Ende.
2. Trennen Sie die Verbindung beim Speichern und stellen Sie sie wieder her. Prüfen Sie, dass der Datensatz genau einmal ankommt.
3. Ändern Sie denselben Datensatz offline auf zwei Geräten. Prüfen Sie, ob Ihre Konfliktregel wie geplant greift.
4. Beenden Sie die App mitten in der Synchronisierung. Öffnen Sie sie erneut und prüfen Sie, ob die Warteschlange weiterläuft.
5. Lassen Sie die Sitzung ablaufen und verbinden Sie dann. Die App sollte eine neue Anmeldung verlangen, ohne Daten zu verlieren.
6. Speichern Sie Medien bei fast vollem Speicher.
7. Prüfen Sie nach einem Update, ob die offene Warteschlange erhalten bleibt.

Der letzte Punkt ist besonders wichtig. Ändert die neue Version das Datenbankschema, müssen offene Datensätze der alten Version migrieren. Sonst löscht ein Update die Offline Daten einer Person. Testen Sie außerdem auf echten Geräten. Ein simulierter Netzabbruch bildet das langsame, wackelige Signal im Aufzug oder im Keller nicht ab. Wenn jemand aus dem Team die App einen echten Arbeitstag lang nutzt, findet er Fehler, die automatische Tests übersehen.

Wie schützen Sie Sicherheit und personenbezogene Daten im Offline Modus?

Sobald Daten auf einem Gerät liegen, gehört der Verlust dieses Geräts zu Ihrem Sicherheitsmodell. Deshalb speichern Sie nur, was die Arbeit braucht, verschlüsseln sensible Felder und leeren lokale Daten beim Abmelden. Vor dem Leeren prüfen Sie allerdings, ob noch ungesendete Datensätze existieren, und warnen die Person. Sonst wird eine Schutzmaßnahme zum Datenverlust.

Planen Sie zudem eine Abmeldung aus der Ferne ein. Verlässt jemand das Unternehmen oder geht ein Gerät verloren, sollte die App lokale Daten bei der nächsten Verbindung löschen. Apps mit personenbezogenen Daten unterliegen außerdem Pflichten zu Speicherdauer und Löschung, etwa nach der DSGVO. Dieser Beitrag ist keine Rechtsberatung; klären Sie diese Punkte mit Ihrer Rechtsberatung oder Ihrem Datenschutzbeauftragten.

Was bestimmt Aufwand und Zeitplan für einen Offline Modus?

Offline Unterstützung gehört zu den Funktionen, die den Umfang einer App am stärksten vergrößern. Trotzdem würde eine einzelne Zahl Sie in die Irre führen, denn entscheidend sind die Zahl der Aktionen und die Komplexität der Konflikte. Eine reine Katalogapp und eine Lagerapp mit vielen Nutzern sind sehr verschiedene Aufgaben.

Diese Faktoren bestimmen den Umfang: wie viele Aktionen offline laufen, wie viele Personen denselben Datensatz bearbeiten, wie hoch die Medienlast ist, ob der Server Synchronisierung schon unterstützt und ob ältere Versionen Daten migrieren müssen. Daher erleichtert es allen die Arbeit, wenn Sie die Fragen oben vor einer Angebotsanfrage beantworten. Läuft Ihr Prozess noch in Tabellen, hilft unser Beitrag Von Excel zu Individualsoftware wechseln bei der Entscheidung.

Wie sieht die abschließende Checkliste für den Offline Modus aus?

Wir haben diesen Leitfaden in eine Liste übersetzt, die Ihr Team vor Projektstart abhaken kann. Notieren Sie zu jedem Punkt eine Antwort:

• Welche Aktionen funktionieren offline, welche brauchen den Server?
• Ist die lokale Datenbank die einzige Quelle für jeden Bildschirm?
• Hat jede Aktion eine festgelegte Schreibstrategie?
• Ist die Konfliktregel je Datentyp definiert?
• Trägt jeder Datensatz eine vom Gerät erzeugte Kennung und eine Version?
• Nutzen Sie einen Vorgangsschlüssel gegen doppelte Anfragen?
• Sehen Personen den Status jedes Datensatzes?
• Haben Medien eine eigene, fortsetzbare Warteschlange?
• Warnt die App beim Abmelden vor ungesendeten Datensätzen?
• Übersteht die offene Warteschlange ein Update?

Jeder Punkt ist somit eine Architekturentscheidung. Zusammengefasst lässt ein guter Offline Modus Menschen arbeiten, ohne an das Internet zu denken. Wenn Sie diese Entscheidungen für Ihr Produkt klären und eine App rund um Ihren echten Arbeitsablauf bauen möchten, erfahren Sie auf unserer Seite App entwickeln lassen, wie wir arbeiten.