Die Renaissance der Local-First-Software: Warum Ihre Apps wieder auf Ihrem Gerät zuhause sind

Im Jahr 2019 veröffentlichte ein Forschungslabor namens Ink & Switch einen Aufsatz, der das Konzept der „Local-First-Software“ vorstellte. Die Prämisse war einfach und die Implikationen waren weitreichend: Anwendungen sollten ihre Daten auf dem Gerät des Nutzers speichern, vollständig ohne Internetverbindung funktionieren und die Cloud lediglich als Synchronisationsschicht betrachten – nicht als Quelle der Wahrheit. Die Resonanz aus der Entwickler-Community war positiv, intellektuell anregend, aber meist theoretisch. Die Werkzeuge, um Local-First-Apps in Produktionsqualität zu bauen, gab es noch nicht wirklich.

Sieben Jahre später sind sie da. ElectricSQL erreichte im März 2025 Version 1.0 und brachte produktionsstabile Postgres-Synchronisation für lokales SQLite. Automerge und Yjs – die beiden dominierenden CRDT-Bibliotheken – sind deutlich ausgereifter. Die Local-First Conference in Berlin zog Forscher, Startups und Ingenieure etablierter Unternehmen an. Und On-Device-AI hat dem architektonischen Ansatz einen neuen kommerziellen Daseinsgrund gegeben, der über Ideologie hinausgeht.

Was Local-First eigentlich bedeutet

Der Begriff wird oft lose verwendet, daher lohnt sich eine präzise Definition. Eine Local-First-Anwendung speichert ihre primären Daten auf dem Gerät des Nutzers – in einer lokalen Datenbank, als einfache Dateien oder im Browser-Speicher – und synchronisiert diese Daten als sekundäre Operation mit anderen Geräten oder einem Server. Die entscheidende Invariante ist, dass die App vollständig ohne Netzwerkverbindung funktioniert. Nicht „es zeigt gecachte Daten“ – sie funktioniert, liest und schreibt, mit vollem Funktionsumfang.

Die ursprünglichen sieben Prinzipien von Ink & Switch umfassen: sofortige Operationen ohne Lade-Spinner, vollständige Offline-Funktionalität, nahtlose Synchronisation über Geräte hinweg, Echtzeit-Zusammenarbeit, Datenlanglebigkeit (die App funktioniert auch, wenn das Unternehmen schließt), Sicherheit standardmäßig und Dateneigentum des Nutzers mit Exportierbarkeit. Die meisten Cloud-First-Apps scheitern an mindestens vier dieser Prinzipien. Die meisten Local-First-Apps, die mit aktuellen Werkzeugen gebaut wurden, können alle sieben erfüllen.

Die Technologie, die es möglich macht: CRDTs

Der Grund, warum Local-First-Synchronisation früher unpraktisch war, sind Merge-Konflikte. Wenn Sie offline ein Dokument auf Ihrem Handy bearbeiten und jemand anderes dasselbe Dokument auf seinem Laptop bearbeitet, wie führen Sie die beiden Versionen zusammen, wenn Ihr Handy wieder online geht? Der naive Ansatz ist, eine Version zu wählen und die andere zu verwerfen – katastrophal für die Zusammenarbeit. Der anspruchsvolle Ansatz nutzt operationale Transformationen – komplexe Algorithmen, die funktionieren, aber einen zentralen Server zur Entscheidungsfindung benötigen.

CRDTs (Conflict-Free Replicated Data Types) lösen dieses Problem mit Mathematik statt Infrastruktur. Ein CRDT ist eine Datenstruktur, die so ausgelegt ist, dass gleichzeitige Änderungen auf mehreren Replikaten immer zu einem konsistenten Ergebnis zusammengeführt werden können – ohne zentralen Koordinator. Die Mathematik garantiert eventuelle Konsistenz – alle Replikate enden im selben Zustand – ohne dass jemals ein Server schlichten muss. Google Docs, Figma und WhatsApp nutzen CRDTs für ihre kollaborativen und geräteübergreifenden Synchronisationsfunktionen.

Für Local-First-Apps bedeutet das: Zwei Handys können dasselbe Dokument bearbeiten, während beide offline sind, und beim Wiederverbinden automatisch ein korrektes zusammengeführtes Ergebnis erhalten. Der Merge-Konflikt-Albtraum, den Entwickler befürchteten, erweist sich in der Praxis für typische Dokument- und Datenbearbeitungsszenarien als weitgehend nicht existent.

Die Werkzeuge sind produktionsreif

Yjs ist der Branchenstandard für Echtzeit-kollaborative Textbearbeitung. Geschrieben in JavaScript mit einem schnellen Rust-Port (Yrs), integriert es sich direkt in ProseMirror, Tiptap und CodeMirror – und deckt damit den Großteil der Rich-Text-Editoren ab. Wenn Sie in den letzten drei Jahren einen webbasierten Dokumenteneditor verwendet haben, haben Sie wahrscheinlich Yjs genutzt, ohne es zu wissen.

Automerge verfolgt einen anderen Ansatz und speichert die vollständige Historie jeder Änderung als erstklassiges Objekt. Das macht es zu einer Art Git für App-Daten: Sie können Branches erstellen, Diffs anzeigen, mergen und Änderungen zwischen Replikaten auswählen. Kompiliert zu WebAssembly für die Nutzung im Web, erkauft es sich mit einem größeren Footprint reichhaltigere Historien-Funktionen.

ElectricSQL besetzt eine andere Nische: Statt CRDTs direkt zu verwalten, synchronisiert es Teile einer PostgreSQL-Datenbank in ein lokales SQLite auf dem Client. Für Teams, die bereits Postgres einsetzen, ist dies der reibungsloseste Weg zur Local-First-Architektur – Ihre bestehende Datenbank bleibt erhalten; Sie fügen eine Synchronisationsschicht davor. Version 1.1, veröffentlicht im August 2025, lieferte im Vergleich zur Vorgängerversion 102-mal schnellere Schreib- und 73-mal schnellere Lesezugriffe. Sie ist bei Trigger.dev im Produktionseinsatz und verarbeitet Millionen täglicher Updates.

Warum der Zeitpunkt 2026 genau richtig ist

Drei konvergierende Kräfte treiben das erneute Interesse an der Local-First-Architektur über den Entwickler-Idealismus hinaus an.

Erstens: On-Device-AI. Neuronale Verarbeitungseinheiten mit 70+ TOPS sind mittlerweile Standard in Flaggschiff-Handys. Apples Foundation Models betreiben ein Sprachmodell mit 3 Milliarden Parametern vollständig auf dem Gerät – auf iPhone und Mac. Wenn KI-Inferenz auf das Gerät verlagert wird, folgen die Daten, mit denen sie arbeitet, natürlich – Sie können keinen wirklich privaten KI-Assistenten haben, wenn alle Ihre Notizen und Dokumente auf den Servern eines Anbieters liegen. Local-First-Datenarchitektur und lokale KI-Inferenz sind ein natürliches Paar.

Zweitens: Cloud-Müdigkeit und Datenschutzregulierung. Jahre der Datenlecks, undurchsichtigen KI-Trainingsrichtlinien und Service-Einstellungen haben die Kosten der Cloud-Abhängigkeit in den Köpfen der Nutzer erhöht. Die Einhaltung von GDPR, HIPAA und CCPA ist dramatisch einfacher, wenn Nutzerdaten auf den Geräten der Nutzer bleiben. Teams im Gesundheitswesen, in der Rechtsberatung und im Finanzdienstleistungssektor werden zunehmend von Local-First-Tools angezogen, gerade weil sie die Compliance-Kalkulation vereinfachen.

Drittens: Leistung. Linears Projektmanagement-Tool – eines der am häufigsten zitierten Beispiele für Local-First-Architektur – speichert seine primären Daten im IndexedDB des Browsers und synchronisiert im Hintergrund. Jede Aktion wird zuerst lokal geschrieben. Das Ergebnis ist eine UI, die sich im Vergleich zu Cloud-First-Tools, die bei jedem Klick einen Roundtrip zum Server machen müssen, sofort anfühlt. Teams beschreiben es durchweg als das schnellste Projektmanagement-Tool, das sie je verwendet haben. Geschwindigkeit, nicht Philosophie, bringt Nutzer zum Umstieg.

Das Geschäftsmodell-Problem – und wie es gelöst wird

Der offensichtliche Einwand gegen Local-First-Software aus geschäftlicher Perspektive: Wenn Nutzer ihre Daten besitzen und frei exportieren können, wofür soll man dann bezahlen? Obsidian, die nach Nutzerzahlen erfolgreichste Local-First-App (über eine Million aktive Nutzer), hat dies klar beantwortet. Die App ist kostenlos und Open Source. Notizen werden als einfache Markdown-Dateien gespeichert, die Ihnen vollständig gehören. Obsidian Sync – ein optionales Add-on für 4 $ pro Monat – bietet verschlüsselte Synchronisation zwischen Geräten. Sie bezahlen für den Service, nicht für die Datenfestsetzung. Das Geschäftsmodell funktioniert, weil das Produkt exzellent ist, nicht weil Nutzer gefangen sind.

ElectricSQL und PowerSync setzen auf das Open-Core-Modell: Die Sync-Engine kann selbst gehostet werden (kostenlos), für die verwaltete Cloud-Version wird bezahlt. Linear erhebt Abonnementgebühren für Team-Features und Integrationen, nicht für die Datenverwahrung. Das Muster zeichnet sich ab: Local-First-Unternehmen verlangen Geld für Bequemlichkeit, Zuverlässigkeit und Kollaborationsfunktionen – nicht dafür, Ihre Daten als Geisel zu nehmen.

Gemessen an der allgemeinen Entwicklervertrautheit ist das Ökosystem noch früh. Eine Local-First-App in Produktion zu bauen, erfordert ein Verständnis von CRDTs, Sync-Semantik und Konfliktlösung auf einem Niveau, das die meisten Anwendungsentwickler bisher nicht benötigt haben. Die Werkzeuge verbessern sich weiter, aber es gibt einen Grund, warum der Ink-&-Switch-Aufsatz den Stand der Local-First-Entwicklung im Jahr 2025 mit React im Jahr 2013 verglich. Die Technologie ist bereit. Dokumentation und Entwicklererfahrung holen auf.