Warum haben sich Local-First-Apps nicht durchgesetzt?

• Local-First-Apps versprechen schnelle Reaktionszeiten und grundlegenden Schutz der Privatsphäre, haben in der Praxis aber die Einschränkung, dass eine echte Offline-Unterstützung sehr schwer umzusetzen ist
• Der wichtigste Grund ist die Komplexität der Synchronisierung: Wenn Daten auf mehreren Geräten gleichzeitig geändert werden, müssen sie am Ende exakt in denselben Zustand konvergieren
• Es gibt zwei große technische Herausforderungen: Unsicherheit der zeitlichen Reihenfolge und Konflikte
• Um dieses Problem zu lösen, ist ein Ansatz mit verteilten Systemdesigns wie Hybrid Logical Clocks(HLCs) und CRDTs erforderlich
• Durch die Nutzung von SQLite-basierten Erweiterungen lässt sich eine zuverlässige und einfache Synchronisierungsarchitektur bereitstellen, die auf allen Plattformen eingesetzt werden kann

---

Das Versprechen und die Realität von Offline-First-Apps

• Offline-First-Apps werben mit sofortiger Reaktion, standardmäßig gewährleisteter Privatsphäre und Nutzbarkeit auch in instabilen Netzwerken ohne Ladezeiten
• In der Realität setzen die meisten Apps Offline-Unterstützung nicht wirklich sauber um; meist werden Änderungen nur lokal zwischengespeichert und später bei bestehender Netzwerkverbindung übertragen
• Solche Implementierungen sind unzuverlässig und führen letztlich zu Warnmeldungen wie „Änderungen werden möglicherweise nicht gespeichert“

Die grundlegende Schwierigkeit der Synchronisierung

• Wer eine Local-First-App baut, erstellt zwangsläufig ein verteiltes System
• Mehrere Geräte können Daten offline unabhängig voneinander ändern, und wenn sie später wieder verbunden werden, müssen sie präzise in denselben Zustand konvergieren
• Dafür gibt es zwei große Herausforderungen
  • Unsicherheit in der Reihenfolge von Ereignissen
  • Konflikte bei denselben Daten

1. Unsicherheit bei der Ereignisreihenfolge

• Ereignisse treten auf mehreren Geräten zu unterschiedlichen Zeitpunkten auf, und je nach Reihenfolge kann sich der Zustand unterscheiden
  • Beispiel: Gerät A setzt x=3, Gerät B setzt x=5 → nach getrennten Offline-Änderungen kann die Synchronisierung zu unterschiedlichen Ergebnissen führen
• Klassische zentrale Datenbanken lösen das mit starker Konsistenz, doch dafür ist globale Synchronisierung nötig, was nicht zu Local-First-Systemen passt
• Am Ende muss für jedes Ereignis auch in einer dynamischen, verteilten Umgebung eine passende Reihenfolge festgelegt werden; es wird also eine Methode benötigt, die ohne zentrale Uhr auskommt

Einführung von Hybrid Logical Clocks(HLCs)

• Hybrid Logical Clocks(HLCs) sind ein einfacher, aber effektiver Algorithmus, mit dem einzelne Geräte sich praktisch auf die Reihenfolge von Ereignissen einigen können
• HLC kombiniert physische Zeitinformationen mit einem logischen Zähler
• Zum Beispiel:
  • Gerät A protokolliert um 10:00:00.100 ein Ereignis, HLC ist dann (10:00:00.100, 0)
  • Gerät B empfängt die Nachricht und erhöht seinen HLC selbst dann auf (10:00:00.100, 1), wenn seine eigene Uhr nachgeht
  • Dadurch lässt sich die exakte Reihenfolge von Ereignissen unabhängig von der Differenz zwischen den physischen Uhren der beiden Geräte bestimmen

2. Das Konfliktproblem

• Die korrekte Reihenfolge allein reicht nicht aus; wenn verschiedene Geräte dieselben Daten unabhängig voneinander ändern, entstehen Konflikte zwangsläufig
• Die meisten Systeme verlangen, dass Entwickler den Code zur Konfliktauflösung manuell schreiben, was Fehlerrisiken und zusätzlichen Wartungsaufwand verursacht

Einsatz von CRDTs

• Der beste Ansatz ist die Verwendung von Conflict-Free Replicated Data Types(CRDTs)
• CRDTs garantieren, dass der Zustand auf jedem Gerät am Ende immer identisch ist, unabhängig von der Reihenfolge der Synchronisierung oder mehrfacher Anwendung
• Die einfachste CRDT-Strategie ist Last-Write-Wins(LWW)
  • Jeder Aktualisierung wird ein Zeitstempel zugewiesen
  • Bei der Synchronisierung wird der Wert mit dem neueren Zeitstempel ausgewählt

Die Vorteile von SQLite

• Für den Aufbau von Local-First-Apps ist eine zuverlässige und leichte lokale Datenbank unverzichtbar, und SQLite ist dafür die beste Wahl
• Wird die Synchronisierung über SQLite-basierte Framework-Erweiterungen implementiert, ergeben sich folgende Vorteile
  • Das Anwenden von Nachrichten ist einfach: aktuellen Wert abfragen → überschreiben, wenn der neue Zeitstempel aktueller ist → andernfalls ignorieren
  • Dieser Ansatz garantiert die Konvergenz des Zustands auf allen Geräten unabhängig von der Reihenfolge der Synchronisierung

Die Bedeutung dieser Architektur

• Diese Struktur ermöglicht eine einfache und hochzuverlässige Synchronisierung
  • Zuverlässigkeit ohne Datenverlust auch nach wochenlangem Offline-Betrieb
  • Deterministische Eigenschaften, die immer zum endgültigen Zustand konvergieren
  • Umsetzung allein mit einer leichtgewichtigen SQLite-Erweiterung ohne schwere Abhängigkeiten
  • Unterstützung für alle wichtigen Plattformen wie iOS, Android, macOS, Windows, Linux und WASM

Empfehlungen für Entwickler

• Es ist sinnvoll, Ansätze zu vermeiden, die Offline-Modus nur mit einer einfachen Request-Queue „nachahmen“
• Stattdessen sollte das Konzept der Eventual Consistency akzeptiert und auf bewährte Technologien aus verteilten Systemen wie HLC und CRDT gesetzt werden
• Statt großer und komplexer Frameworks ist eine kleine Architektur ohne Abhängigkeiten vorzuziehen
• So kann eine App letztlich Vorteile wie sofortige Ausführung, Offline-Nutzbarkeit und standardmäßig gewährleistete Privatsphäre realisieren

Hinweis auf das Open-Source-Projekt SQLite-Sync

• Wer an einer sofort produktionsreifen, plattformübergreifenden Offline-First-Engine interessiert ist, kann sich die Open-Source-Erweiterung SQLite-Sync ansehen

[GN⁺]

Hacker-News-Kommentare

• CRDTs (Conflict-Free Replicated Data Types) werden zwar als Lösung angepriesen, aber ein CRDT-Modell zu bauen, das sowohl den intuitiven Erwartungen der Nutzer als auch konsistenter Business-Logik entspricht, ist wirklich schwer. Außerdem muss man das Datenmodell in Nachrichtenbündel umwandeln und daraus den tatsächlichen Zustand fortlaufend rekonstruieren, was ein riesiger Alptraum ist.
  • Es gibt eine Initiative namens BRAID als neuen Webstandard. Sie zielt auf einen Standard für Web-State-Synchronisation ab und will OT- und CRDT-Techniken auf HTTP anwenden, um im Kern ein synchronisiertes Web zu schaffen, das für Menschen und Maschinen gleichermaßen freundlicher ist. Braid verbessert die Netzwerkleistung und unterstützt native P2P-, kollaboratives Editieren und die Entwicklung Local-First-Web-Apps. Relevante Links: BRAID-Treffen, Braid-HN-Diskussion, RESTful-API-Diskussion, Erklärung zu Braid HTTP
  • Über CRDTs wird oft gesprochen, als wären sie eine Universallösung, aber in der Praxis ist automatisches Mergen keineswegs einfach. Technisch kann auch ein Last-Writer-Wins-Algorithmus als CRDT gelten, aber bei komplexen Text-Merges ist es nahezu unmöglich, sowohl Nutzerintention als auch Erwartungen vollständig zu respektieren. In manchen Situationen kann schon der Versuch, mit CRDTs zu mergen, sogar der falsche Ansatz sein. Wenn zum Beispiel zwei Personen gleichzeitig denselben Besprechungsraum buchen, sollte nicht ein Algorithmus entscheiden, sondern die Nutzer sollten den Konflikt selbst erkennen und lösen.
  • Ich stimme zu, dass das ein Bereich ist, den man sich nur mit Mut vornimmt. Es gibt auch eine „ohne CRDTs“-Alternative für weniger Wagemutige, siehe hier.
  • Unser Team baut Local-First-Apps und ignoriert Konfliktsituationen einfach. Die letzte Änderung gewinnt. Die meisten Konflikte sind trivial oder lassen sich leicht lösen, etwa über ein Audit-Log, oder sie sind von vornherein nicht automatisch auflösbar. Wenn in einem Task-Tracker mit Offline-Support zwei Personen gleichzeitig dieselbe Aufgabe starten, muss das ohnehin über den Business-Prozess geregelt werden.
• Früher war fast jede Software Local First, und das war selbstverständlich. Heute wird die Welt aber vollständig von Kontrolle und Gewinnoptimierung getrieben, wodurch Menschen häufiger die Leidtragenden sind. Selbst wenn Unzufriedenheit entsteht, gibt es oft keine echte Alternative.
  • Als wir früher On-Premises- und Self-Hosted-Produkte gebaut haben, war die größte Kundenbeschwerde, dass es keine Cloud-Option gab. Die meisten Unternehmen wollen nicht selbst hosten und zahlen lieber ein monatliches Abo, damit jemand anderes sich darum kümmert. HN unterschätzt anscheinend, wie groß die tatsächliche Nachfrage nach Cloud-Services ist.
  • Die Behauptung „Wenn Menschen einen Service wollen, der sie weniger ausnutzt, müsste man damit doch Geld verdienen können“ ist ökonomisch nicht korrekt. Das Problem ist, dass Menschen ein gewisses Maß an Nachteilen tatsächlich in Kauf nehmen. Mit mehr Bildung oder Risikobewusstsein könnte sich das vielleicht ändern, aber das wäre eine extrem schwere Aufgabe.
  • Als Alternative könnte man FOSS (Free and Open Source Software) sehen.
• Ich wünschte, Apps würden nicht alle Inhalte ausschließlich vom Online-Zustand abhängig machen. Selbst Tesla-GPS cached bereits geladene Kacheln nicht, sodass im Offline-Modus auf der Karte gar nichts angezeigt wird. Auch Apps wie Peacock oder Kanopy behalten weder die Medienliste noch die gerenderten Objekte auf dem Gerät. Obwohl bereits 95 % der Inhalte auf dem Gerät vorhanden sind, wird das nicht aktiv genutzt. Man müsste nur die UI als dirty markieren und auf den Erfolg des asynchronen Speicherns warten. Für besseres Offline-App-Design braucht es oft keine großen Architekturänderungen, sondern nur bessere Gewohnheiten.
  • Viele Probleme lassen sich lösen, indem man Cache-Control in API-Antworten korrekt nutzt und dies auf der Netzwerkebene sauber beachtet. So kann man die Cache-Lebensdauer serverseitig ändern, ohne ein App-Update auszurollen.
  • Google Maps erlaubt es, Offline-Karten manuell für bestimmte Bereiche herunterzuladen, und man kann mehrere Regionen gleichzeitig cachen. Ich habe das bei Besuchen in Nationalparks gut genutzt.
  • Zur Aussage, dass keine Designänderung nötig sei: Ich glaube, viele Anbieter wollen in Wirklichkeit einfach mehr Daten sammeln. Apple bot zum Beispiel auch Offline-Karten an, ließ die Daten aber absichtlich ablaufen, um Nutzer stärker an sich zu binden. Ich vermute, dass auch bei Tesla- oder Google-Kartenkacheln solche versteckten Motive eine Rolle spielen.
• Oft wird so stark auf „politisch heiße“ Themen wie Local First oder Dezentralisierung fokussiert, dass man dabei den eigentlichen Kernnutzen vergisst, den Menschen wirklich wollen.
  • Beim Wechsel zu Immich dachte ich, ich würde wegen Self-Hosting Abstriche machen müssen, war dann aber überrascht, dass es deutlich besser ist als Apple oder Google. So ein Produkt ist selten wie ein Einhorn.
• Ich denke, dass Local-First-Apps letztlich vor allem aus wirtschaftlichen Gründen nicht populär sind. SaaS- oder werbefinanzierte Modelle sind etabliert, während Local-First-Apps deutlich weniger profitabel sind. Menschen, die dieses Modell bevorzugen, legen Wert auf Eigenschaften wie Datensouveränität, Ende-zu-Ende-Verschlüsselung und Offline-Nutzung, die mit bestehenden Geschäftsmodellen kollidieren. Am Ende bleibt oft nur, auf die Leidenschaft der Open-Source-Community zu setzen.
  • Inzwischen scheint man nur noch zwischen „mit Geld + Daten bezahlen“ oder „Werbung anschauen“ wählen zu können; ein Modell, bei dem man einfach echtes Geld zahlt und die eigenen Daten geschützt bleiben, wird ausgeschlossen.
  • Ich baue selbst eine Local-First-App namens Relay, die Obsidian eine Art Google-Docs-artige Zusammenarbeit hinzufügt. Ich halte das Geschäftsmodell für ziemlich ungewöhnlich. Der Service ist in eine „globale Identitätsschicht“ und den „Relay Server“ (Open Source/Self-Hosted) aufgeteilt, sodass Nutzer die volle Kontrolle über ihre Dokumentinhalte behalten können. Es bietet einfaches Single Sign-On und Rechteverwaltung und stößt besonders bei Firmen aus den Bereichen AI und AI Safety oder bei Unternehmen mit hohen Compliance-Anforderungen auf Interesse. Link: Relay.md
  • Ich beobachte oft, dass Verbraucher etwas am Ende gar nicht kaufen, weil nur ein Abo angeboten wird. Sie wollen es erst einmal kaufen und später nutzen, aber Einschränkungen wie Aktionszeiträume oder höhere Preise beim späteren Wiederkommen nehmen ihnen komplett die Kaufmotivation. Ich glaube nicht, dass das das optimale Geschäftsmodell ist.
  • Ich glaube nicht, dass replizierte Datenstrukturen das eigentliche Problem sind. Selbst vollständig Local-First aufgebaute Singleplayer-Spiele verlangen oft über ihren Launcher eine Internetverbindung.
  • Ein ernstes Problem bei Local-First-Apps ist auch die Komplexität. Sie müssen auf allen möglichen Geräten und in verschiedenen Umgebungen laufen, während Cloud-First-Apps nur gegen eine einzige Serverumgebung entwickelt werden müssen und deshalb vergleichsweise einfacher und günstiger im Unterhalt sind.
• Obwohl Desktop- und Mobile-Software heute manchmal wie eine seltsame Ausnahme behandelt werden, sind sie nach wie vor eine sehr verbreitete Form der Softwareverteilung. Wenn man dagegen versucht, Local-First-Funktionen im Browser umzusetzen, handelt man sich zusätzlich die Nachteile des Browsers ein, etwa Probleme bei der Integration mit dem Host-System.
• Vielleicht übersehe ich etwas, aber ich hätte gedacht, dass „Local First“-Apps im Allgemeinen ganz normal sind. Die meisten Nutzer verwenden doch viele Apps, die im Kern offlinebasiert sind. Falls eigentlich „Local-First-Web-Apps“ gemeint sind, klingt das plausibler. Tatsächlich ist schon das Konzept einer „Local-First-Web-App“ in sich widersprüchlich.
  • Ich würde zurückfragen, ob die meisten Apps heute wirklich Local First sind, also direkt vom Nutzer bezahlt und lokal genutzt werden. Abgesehen von Spielen scheint es solche Unternehmen kaum noch zu geben, und selbst Singleplayer-Spiele verlangen inzwischen oft Internetzugang wegen DRM, Anti-Cheat oder Updates.
  • Mit „Local First“ ist hier gemeint, dass Apps nicht primär auf Cloud-Speicherung basieren, sondern lokale Daten zum Ausgangspunkt machen und nur zusätzlich Synchronisation mit der Cloud unterstützen.
• Auch Offline-First-Apps unterscheiden sich letztlich nicht davon, dass bei instabiler Netzverbindung ein Ladespinner erscheint. Google Docs hängt zum Beispiel erst daran fest zu prüfen, ob ein Dokument aktuell ist, und öffnet es erst sofort, wenn man per Airplane Mode die Verbindung komplett kappt. Spotify bleibt sogar bei bereits gespeicherten Playlists hängen, weil noch Online-Zusatzinformationen geladen werden sollen. Instabile Verbindungen sind damit das größte Ärgernis bei der Entwicklung von Offline-Apps, weil Anwendungen immer noch ein weiteres Mal auf Cloud-Daten zugreifen wollen.
• Auch die Lösung im Artikel ist an ein geschlossenes Cloud-Angebot gebunden. Wie bei Firebase ist das an sich nicht schlimm, aber es ist schade, dass das nicht klar gekennzeichnet wird und stattdessen Formulierungen wie „nur eine sqlite-Erweiterung“ verwendet werden, obwohl in Wirklichkeit nur eine kommerzielle Cloud unterstützt wird. Anbieter wie Powersync oder ElectricSQL sind da wenigstens transparenter, und Powersync erlaubt sogar Self-Hosting.
  • Ich bin unsicher, ob sich das Local-First-Konzept überhaupt auf Developer-Tools anwenden lässt. Es lohnt sich wohl zu prüfen, ob sich mit SQLite-Sync-artigen Tools Software auf Basis lokaler Speichermodelle bauen lässt. ElectricSQL kann self-hosted betrieben werden, und ich sollte meine Liste von „sqlite sync“-Tools wohl weiter pflegen. Relevante Links: local-first Originalartikel, SQLSync, SQLiteSync, SQLite-Sync
• Ich denke, wir brauchen mehr reine Local-Only- und Self-Hosted-Apps. Oder alternativ föderierte Strukturen. Ich hatte immer das Gefühl, dass die Netzwerkinfrastruktur dafür lange ein Hindernis war, aber mit Lösungen wie Tailscale dürfte so etwas deutlich einfacher werden.
  • Ich arbeite an Präsentationssoftware, die lokal zwingend gut funktionieren muss, aber gleichzeitig von überall zugänglich sein soll. Beides gleichzeitig zu erfüllen, ist schwieriger als gedacht. Mit dem technischen Fortschritt werden Direct Connections oder P2P-Implementierungen wie WebRTC allerdings einfacher. Das tatsächlich in ein Produkt zu integrieren und zu testen, bleibt noch herausfordernd. Trotzdem glaube ich, dass es künftig immer mehr Software geben wird, die sowohl Local First als auch stark im Networking ist. Es ist Open Source. Weitere Infos stehen im Profil.
  • Ich erkunde diesen Bereich in letzter Zeit ebenfalls mit großem Interesse. Mehr dazu gibt es hier. Es macht ziemlich viel Spaß, Apps auf diese neue Art zu bauen.