Offline-first ohne Benutzerkonto: Warum meine Apps lokal arbeiten

Was „Offline-first“ eigentlich bedeutet

Bei den meisten Cloud-Apps liegt die eigentliche Datenbank auf einem Server. Was du auf dem Smartphone siehst, ist im Grunde nur eine Zwischenkopie. Jede Änderung muss erst beim Server ankommen, sonst ist sie „nicht passiert“. Ohne Verbindung zeigt die App bestenfalls einen Ladekreis, schlimmstenfalls gar nichts.

Offline-first dreht dieses Verhältnis um. Die Daten auf deinem Gerät sind die primäre Kopie. Die App liest und schreibt lokal und ist damit sofort bedienbar – unabhängig davon, ob gerade WLAN oder Mobilfunk verfügbar ist. Ein Server kann trotzdem eine Rolle spielen, aber nur als Ergänzung: für eine Sicherung, für den Abgleich zwischen Geräten oder für eine bewusst gestartete Online-Funktion.

Die Autoren Martin Kleppmann, Adam Wiggins, Peter van Hardenberg und Mark McGranaghan haben diese Idee 2019 im Essay „Local-first software“ ausführlich beschrieben. Sie nennen sieben Ideale, darunter schnelle Reaktion ohne Wartezeit, „das Netzwerk ist optional“, Langlebigkeit der Daten, Datenschutz als Grundeinstellung und die Kontrolle der Nutzer über ihre eigenen Daten. Nicht jede App muss alle sieben Punkte erfüllen. Für meine Werkzeuge sind aber vor allem drei entscheidend: Offline-Fähigkeit, Datenschutz und Kontrolle.

Warum ich mich für lokale Daten entschieden habe

Meine Apps sind kleine, fokussierte Werkzeuge: ein Subnetzrechner, eine Port-Dokumentation, eine Packliste, ein Punktezettel für Doppelkopf. Keine davon braucht für ihre Kernfunktion einen Server. Ein Benutzerkonto würde dort vor allem eines bringen: zusätzliche Daten, die ich speichern, schützen und irgendwann wieder löschen müsste.

Deshalb gilt für meine Apps grundsätzlich:

• Lokale Speicherung: Eingaben, Projekte, Favoriten und Einstellungen werden auf dem Gerät gespeichert. Ich erhalte keinen automatischen Zugriff auf Inhalte, die nur lokal liegen.
• Kein Benutzerkonto: Für die lokale Nutzung musst du dich bei mir nirgends registrieren.
• Bewusste Exporte: JSON-, CSV- oder PDF-Exporte, Backups und das Teilen von Daten passieren nur, wenn du sie selbst auslöst.
• Optionale Synchronisation: Einige Apps bieten Sicherung oder Abgleich über iCloud oder Google Drive an. Das ist freiwillig; wenn du es nutzt, gelten zusätzlich die Bedingungen von Apple oder Google.

Bei einigen Apps, etwa der OT Toolbox und OT SwitchPort, kommt hinzu: kein Tracking und keine Werbung. Und wo eine App tatsächlich ins Netz muss, etwa beim Online-Live-Spiel in Würfly oder bei den Prüfungen im OT Port Checker, startet das nur durch eine aktive Auswahl von dir. Die Details stehen je App in der Datenschutzerklärung.

Datenschutz: Datenminimierung als Grundprinzip

Die DSGVO formuliert in Artikel 5 eine Reihe von Grundsätzen. Einer davon ist die Datenminimierung: Personenbezogene Daten müssen dem Zweck angemessen und erheblich sowie auf das für die Zwecke der Verarbeitung notwendige Maß beschränkt sein. Artikel 25 ergänzt das um „Datenschutz durch Technikgestaltung“ und datenschutzfreundliche Voreinstellungen: Schon bei der Konstruktion sollen technische Maßnahmen dafür sorgen, dass standardmäßig nur die erforderlichen Daten verarbeitet werden.

Eine lokale App ohne Konto ist eine sehr direkte Umsetzung dieses Gedankens. Daten, die ich nie auf einen Server übertrage, muss ich dort weder absichern noch löschen – und sie können dort auch nicht abhandenkommen. Das ersetzt keine rechtliche Prüfung im Einzelfall, aber es senkt die Angriffsfläche deutlich. Auch das Local-first-Essay weist darauf hin, dass zentrale Datenbanken mit den Daten vieler Nutzer ein attraktives Ziel für Angreifer sind.

Offline-first im OT-Umfeld

Besonders wichtig ist der Ansatz für meine Apps aus dem Bereich Netzwerk und Automatisierung. Produktionsnetze sollen nach gängigen Empfehlungen wie dem NIST-Leitfaden SP 800-82 segmentiert und vom Büronetz getrennt sein. In der Praxis heißt das: Wer an einem Schaltschrank steht, hat oft kein Internet – und soll es aus Sicherheitsgründen auch nicht haben.

Ein Werkzeug, das erst einen Cloud-Dienst erreichen muss, hilft in dieser Situation nicht weiter. Eine Offline-first App dagegen funktioniert dort genauso wie im Büro. Das OT Lexikon und OT Erste-Hilfe halten ihre Inhalte lokal vor, die OT Toolbox rechnet ohne Verbindung, und in OT SwitchPort bleibt die Port-Dokumentation auf dem Gerät verfügbar, auch wenn der Schaltschrank im Funkloch steht.

Dazu kommt ein organisatorischer Vorteil: Je nach Unternehmen gibt es Vorgaben, wohin Anlagendokumentation übertragen werden darf. Wenn die Daten lokal bleiben und nur bewusst exportiert werden, behältst du selbst die Kontrolle darüber, wo IP-Adressen, Schaltschrankfotos oder Port-Belegungen landen.

Die Nachteile – ehrlich betrachtet

Offline-first ist kein Allheilmittel. Der Ansatz hat Grenzen, die ich bewusst in Kauf nehme:

Sicherung liegt bei dir

Wenn das Gerät verloren geht und kein Backup existiert, sind die Daten weg. Das Local-first-Essay nennt das klar: Mit der Kontrolle über die Daten kommt Verantwortung, etwa für Backups. Deshalb bieten viele meiner Apps Export- und Backup-Funktionen an. Nutzen musst du sie aber selbst.

Was du wohin sicherst und wo deine Wiederherstellungscodes liegen, kannst du in der Notfall-Mappe Digital festhalten, ganz ohne dort Passwörter einzutragen.

Mehrere Geräte sind aufwendiger

Ein zentraler Server macht den Abgleich zwischen Smartphone und Tablet einfach. Ohne ihn braucht es Synchronisationsdienste wie iCloud oder einen manuellen Export. Werden dieselben Daten parallel auf zwei Geräten geändert, können Konflikte entstehen, die eine Cloud-App einfacher auflöst.

Gemeinsames Arbeiten ist eingeschränkt

Echtzeit-Zusammenarbeit wie in Online-Dokumenten ist mit rein lokalen Daten schwer umzusetzen. Wo meine Apps gemeinsame Bearbeitung anbieten, geschieht das optional über die Synchronisationsdienste der Plattform.

Wann eine Cloud trotzdem die bessere Wahl ist

Ich halte Cloud-Dienste nicht grundsätzlich für schlecht. Wenn viele Personen gleichzeitig an denselben Daten arbeiten, wenn eine zentrale Instanz Buchungen, Zahlungen oder Freigaben verwalten muss oder wenn Daten von überall ohne Vorbereitung erreichbar sein sollen, spielt eine Server-Architektur ihre Stärken aus. Auch das Local-first-Essay grenzt sich ausdrücklich von Diensten wie Banking oder Onlinehandel ab, die zentral gut aufgehoben sind.

Die Frage ist also nicht „Cloud oder lokal“, sondern: Wer braucht die Daten, wo und wann? Für ein Werkzeug, das eine Person am Einsatzort nutzt, lautet die Antwort fast immer: auf dem eigenen Gerät, sofort und ohne Umweg. Genau für diesen Fall baue ich meine Apps. Wo Zusammenarbeit wirklich gebraucht wird, ergänze ich sie gezielt und optional, statt die ganze App davon abhängig zu machen.

Woran du eine gute Offline-first App erkennst

Wenn du selbst Apps auswählst oder entwickelst, helfen ein paar einfache Prüfungen:

1. Flugmodus-Test: Schalte WLAN und Mobilfunk aus. Funktioniert die Kernfunktion weiter?
2. Konto-Frage: Brauchst du für die Grundfunktion wirklich ein Konto, oder nur für Zusatzdienste?
3. Export: Kommst du in einem offenen Format wie CSV, JSON oder PDF an deine Daten?
4. Transparenz: Steht klar dabei, welche Daten lokal bleiben und welche übertragen werden?

Für mich als Entwickler ist der Ansatz auch eine Frage der Langlebigkeit. Eine App, die keinen eigenen Server braucht, funktioniert weiter, solange sie auf deinem Gerät läuft. Deine Daten hängen nicht davon ab, dass ein Dienst in fünf Jahren noch betrieben wird.

Häufige Fragen zu Offline-first Apps

Quellen

• Kleppmann u. a.: Local-first software (Ink & Switch, 2019)
• Art. 5 DSGVO – Grundsätze der Verarbeitung
• Art. 25 DSGVO – Datenschutz durch Technikgestaltung
• NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security
• DMNK Digital: Datenschutzerklärung

Stand: 15. Oktober 2026.