Warum meine Apps offline funktionieren

Es gibt einen Moment, in dem sich entscheidet, ob eine App etwas taugt: wenn man sie genau dann braucht, wenn das Netz weg ist. Im Wartebereich einer Behörde, im Keller beim Zählerstand ablesen, auf dem Stellplatz irgendwo in Frankreich.

Deshalb beginnt bei mir jede App mit derselben Entscheidung: Die lokale Datenbank ist die Wahrheit, nicht der Server.

Die Datenbank ist die einzige Quelle

Konkret heißt das: Die App liest niemals direkt aus dem Netz. Sie liest aus der lokalen Room-Datenbank, und die UI beobachtet diese Datenbank als Datenstrom. Ob gerade eine Synchronisation läuft, ist für die Oberfläche unerheblich.

@Dao
interface EintragDao {
    @Query("SELECT * FROM eintraege ORDER BY datum DESC")
    fun beobachteAlle(): Flow<List<Eintrag>>
}

Der Effekt ist unspektakulär und genau deshalb richtig: Es gibt keinen Ladespinner, keinen Leerzustand beim Start und keinen Fehlerdialog, weil das WLAN im Flur schwächelt. Die Daten sind einfach da.

Kein Konto, keine Registrierung

Die zweite Konsequenz ist eine Produktentscheidung. Wenn alles lokal liegt, braucht niemand ein Benutzerkonto, um loszulegen. Keine Registrierung, keine E-Mail-Bestätigung, keine Passwörter, die vergessen werden können.

Für die Behördenhelfer-Apps ist das mehr als Bequemlichkeit. Dort trägt man ein, wann das Sorgerecht geklärt wurde oder welcher Pflegegrad beantragt ist. Solche Daten gehören auf das Gerät der Nutzerin und nirgendwo sonst hin.

Was nie hochgeladen wird, kann auch nicht geleakt werden. Die einfachste Datenschutzmaßnahme ist, Daten gar nicht erst einzusammeln.

Was man dafür aufgibt

Ehrlicherweise kostet dieser Ansatz etwas:

• Kein Gerätewechsel per Knopfdruck. Ein neues Handy bedeutet Export und

Import, nicht Anmelden und fertig.

• Keine serverseitigen Auswertungen. Ich weiß nicht, welche Checkliste am

häufigsten abgebrochen wird. Feedback kommt per E-Mail oder gar nicht.

• Migrationen sind heikel. Ein Fehler im Schema-Update trifft die Daten der

Nutzer direkt, ohne Backup auf einem Server.

Der letzte Punkt ist der ernsteste. Jede Schema-Änderung bekommt deshalb eine explizite Migration und einen Test, der gegen die vorherige Datenbankversion läuft. fallbackToDestructiveMigration() steht in keinem meiner Projekte.

Export als Sicherheitsnetz

Statt einer Cloud gibt es einen Export. Bei den Behördenhelfer-Apps als PDF, das man ohnehin zum Amt mitnehmen will, bei den Tagebuch-Apps zusätzlich als strukturierte Datei zum Wiedereinlesen.

Das ist weniger komfortabel als eine Synchronisation – aber es ist ein Format, das auch dann noch lesbar ist, wenn es die App eines Tages nicht mehr gibt. Bei Software, in die jemand über Monate Daten einträgt, halte ich das für die wichtigere Eigenschaft.

Fazit

Offline-First ist kein Feature, das man nachrüstet. Es ist eine Entscheidung am ersten Tag, die danach fast jede weitere Entscheidung beeinflusst – von der Datenhaltung über das Onboarding bis zum Geschäftsmodell. Für Apps, die im Alltag und nicht im WLAN benutzt werden, ist es aus meiner Sicht die richtige.