In der Heizungskellerzeile eines Nachkriegsbaus ist der Empfangsbalken leer. Im Aufzugsschacht im zweiten Untergeschoss sowieso. Und in der Tiefgarage mit 180 Stellplätzen zwischen den armierten Betonwänden wechselt das Smartphone je nach Standort zwischen „kein Netz”, „E” und gelegentlich „LTE”. Wer einen Hausmeister oder Techniker mit einer Portal-App in diese Umgebung schickt und von ihm erwartet, das Übergabeprotokoll einer Wohnungsrückgabe live in einer Online-Maske zu erfassen, erzeugt eines von zwei Ergebnissen: entweder verlorene Daten oder eine Rückkehr zum Papierprotokoll, das abends auf dem Schreibtisch der Verwaltung landet und dort erneut abgetippt werden muss.
Beide Ergebnisse sind in einer digitalisierten Hausverwaltung nicht akzeptabel. Die Antwort darauf ist keine neue Bedienoberfläche und auch kein weiterer Mobilfunkvertrag, sondern eine andere Architekturentscheidung: Offline-First. In diesem Modell ist die mobile Anwendung auch ohne Netzverbindung voll funktionsfähig, speichert Daten zunächst lokal auf dem Gerät und gleicht sie mit dem Server ab, sobald wieder ein Signal vorhanden ist.
Was „Offline-First” technisch bedeutet
Der Begriff wird in Produkt-Broschüren inflationär verwendet. Seriös ist eine Anwendung dann offline-fähig, wenn sie drei Eigenschaften erfüllt.
Erstens: Der Start der Anwendung muss ohne Netzverbindung gelingen. Das verlangt einen Service Worker, der Anwendungs-Code, statische Assets und die zuletzt geladenen Fachdaten in einem versionierten Cache vorhält. Wer sich beim Start auf eine Online-Authentifizierung verlässt, ist nicht offline-fähig, sondern nur offline-tolerant — und das auch nur für die Dauer eines gültigen Session-Tokens.
Zweitens: Erfasste Daten, Fotos und Signaturen müssen lokal in einer strukturierten, durchsuchbaren Datenbank liegen. Auf modernen Browsern ist das IndexedDB, auf nativen Plattformen eine SQLite-gestützte Ablage. Ein einfaches Ablegen als Datei im Local Storage ist ungeeignet, weil es weder transaktional noch zuverlässig quotenfest ist. Zusätzlich muss der Browser über navigator.storage.persist() angewiesen werden, den Speicher nicht automatisch zu verwerfen, wenn der Arbeitsspeicher des Geräts knapp wird.
Drittens: Es braucht eine explizite Outbox — eine lokale Warteschlange mit allen noch nicht synchronisierten Änderungen, jede einzeln identifizierbar über eine client-seitig erzeugte UUID. Erst wenn der Server den Empfang einer Operation quittiert hat, verschwindet sie aus der Outbox. So bleibt ein abgestürztes Gerät, ein unterbrochener Upload oder ein Tunnel auf der Rückfahrt zur Verwaltung ohne Datenverlust.
Eine Anwendung, die diese drei Eigenschaften nicht sauber umsetzt, ist bestenfalls robust gegen kurze Netzausfälle, aber nicht offline-first.
PWA oder native App — die pragmatische Entscheidung
Vor dem Bau eines solchen Systems steht die Grundsatzentscheidung: native iOS/Android-App oder installierbare Progressive Web App (PWA). Beide Wege sind technisch gangbar, unterscheiden sich aber in Aufwand, Wartungskosten und Reichweite.
Eine native App über die App-Stores von Apple und Google zu veröffentlichen erfordert Entwickler-Konten, Review-Prozesse, getrennte Code-Basen oder ein Cross-Platform-Framework, verpflichtende Anpassungen bei jeder iOS- und Android-Major-Version sowie eine separate Rollout-Strategie für jede neue Funktion. Für eine Hausverwaltung mit mittlerer IT-Mannschaft ist der Unterhaltsaufwand erheblich.
Eine installierbare PWA — geladen aus dem Browser, auf dem Homescreen verankert, im Vollbild laufend wie eine native App — liefert inzwischen die entscheidenden Primitive für Offline-Arbeit: Service Worker, IndexedDB, Cache Storage, Background Sync, Zugriff auf Kamera und Geolocation-API, Datei-Zugriff für Foto-Uploads. Auf iOS sind Einschränkungen zu kennen — Speicherquoten, Hintergrund-Sync mit engeren Limits, Verwerfungsverhalten nach längerer Inaktivität —, die sich aber durch sorgfältige Implementierung auffangen lassen.
Die Entscheidung fällt damit in den meisten Fällen zugunsten der PWA aus. Sie teilt die Code-Basis mit dem Portal, läuft auf privaten wie auf Firmen-Smartphones, erzwingt kein Enterprise-Mobile-Device-Management und lässt sich bei Bedarf später über Capacitor oder Tauri in eine nativ signierte Store-App portieren. Wer heute eine unumkehrbare Native-Entscheidung trifft, bezahlt dafür Jahr für Jahr in Form doppelter Wartung.
Das Sync-Modell: Operation-Log statt naiver Datenbank-Replikation
Der anspruchsvollste Teil einer Offline-First-Architektur ist nicht die lokale Erfassung, sondern die Synchronisation. Zwei Hausmeister, die am selben Vormittag an unterschiedlichen Standorten einen Schadensbericht zu derselben Anlage eröffnen, erzeugen konkurrierende Änderungen. Ein naiver Ansatz — der Client schickt am Ende seinen kompletten lokalen Stand, der Server akzeptiert — führt unweigerlich zu überschriebenen Daten.
Stabiler ist ein Operation-Log. Jede Änderung wird lokal als einzelne Operation protokolliert, mit Zeitstempel, Geräte-Kennung, client-seitig erzeugter UUID und einem kompakten Diff. Beim Sync werden diese Operationen einzeln und idempotent an den Server übertragen. Idempotent bedeutet: Wenn der Hausmeister auf der Autobahn aus einem Funkloch kommt und sein Gerät unklar ist, ob die letzte Operation ankam, kann das Gerät die Operation schlicht erneut senden — der Server erkennt sie anhand der UUID und verarbeitet sie nicht doppelt.
Bei Konflikten auf Feld-Ebene greift dann Last-Write-Wins mit expliziter Konfliktliste. Das System merge-t nicht heimlich, sondern legt die konkurrierenden Werte beiseite und zeigt sie dem Verwalter oder dem zuständigen Hausmeister in einer Auflösungs-Ansicht. Das ist bewusst kein CRDT-Ansatz mit automatischer Konvergenz — in einer Domäne, in der falsche Zahlenwerte in einem Übergabeprotokoll zu rechtlichen Auseinandersetzungen führen können, ist die Auto-Merge-Heuristik das größere Risiko als ein Klick mehr in der Verwaltung.
Was offline erfasst werden muss — und was nicht
Für den Arbeitsalltag eines Hausmeisters oder Technikers sind drei Kern-Prozesse entscheidend, die ohne Netz funktionieren müssen.
Das Übergabeprotokoll nach Wohnungsrückgabe, strukturiert nach Räumen, Zählerständen, Schlüsseln, Mängeln und Fotodokumentation, abgeschlossen mit Unterschriften von Übergebendem und Übernehmendem. Fotos werden auf dem Gerät gemacht, lokal gespeichert und später hochgeladen. Vor dem Upload müssen EXIF-Metadaten gestrippt werden, insbesondere GPS-Koordinaten, sofern diese nicht ausdrücklich Teil des Protokolls sein sollen — Art. 5 Abs. 1 lit. c DSGVO (Datenminimierung) verlangt, dass nicht mehr Daten erhoben werden als für den Zweck nötig.
Die Abarbeitung von Hausmeister-Aufgaben — Aufträge aus der Tagesplanung, die auf dem Gerät mit Erledigungszeitpunkt, Befundnotiz und optional Foto quittiert werden. Jede Erledigung ist eine Operation im Sync-Log, die eine Aufgabe von „offen” auf „erledigt” setzt.
Die Ad-hoc-Schadensmeldung am Objekt — ein vorbeigehender Hausmeister sieht einen Wasserschaden im Treppenhaus, dokumentiert ihn mit Foto und Text und legt damit ein neues Ticket an, das später im Büro bewertet und einem Gewerk zugeordnet wird.
Bewusst nicht in diesen Offline-Umfang gehören abrechnungskritische Buchungen, Mietpreis-Änderungen oder WEG-Beschlussfassungen. Diese Prozesse sind ohne konsistenten Serverstand nicht sinnvoll erfassbar und werden weiterhin im Portal am Schreibtisch erledigt.
Beweiskraft von Fotos, Signaturen und Zeitstempeln
Ein Übergabeprotokoll ist kein nettes Protokoll, sondern im Streitfall Beweismittel. Die Anforderungen an die Beweiskraft sind damit nicht technischer, sondern rechtlicher Natur, und sie sind unabhängig davon, ob das Protokoll auf Papier oder digital entsteht.
Die Unterschrift auf dem Touchscreen ist eine einfache elektronische Signatur im Sinne der eIDAS-Verordnung (Art. 3 Nr. 10 VO (EU) 910/2014). Sie ist nicht einer qualifizierten elektronischen Signatur gleichgestellt, ist aber als Beweismittel im Zivilprozess zulässig (Art. 25 Abs. 1 eIDAS-VO). Für das Übergabeprotokoll nach § 546 BGB reicht das regelmäßig aus, weil für die Rückgabepflicht selbst kein Formerfordernis besteht und das Protokoll der Beweisführung im Rahmen von § 538 BGB (vertragsgemäße Abnutzung) dient. Entscheidend ist, dass der Unterzeichnende identifizierbar ist und die Zuordnung zum dokumentierten Zustand nachvollziehbar bleibt. Eine auf dem Gerät erzeugte Signatur mit Zeitstempel, Gerätekennung und PDF-Einbettung erfüllt diese Anforderung.
Fotos benötigen eine nachweisbare Integritätskette. Einmal hochgeladen, werden sie in einem Cloud-Objektspeicher mit Hash-Prüfsumme abgelegt und über eine signierte URL ausgeliefert. Veränderungen nach der Synchronisation sind durch Hash-Vergleich erkennbar. Der Zeitpunkt der Aufnahme wird dabei sauber getrennt in „Client-Zeit des Geräts” und „Server-Zeit der Annahme”. Eine allein auf das Gerät gestützte Zeitangabe ist im Zivilprozess angreifbar, weil die Systemzeit eines Smartphones manipulierbar ist. Eine zusätzliche server-seitige Protokollierung — die aber erst mit der nächsten Synchronisation stattfindet — kompensiert das.
DSGVO: Was auf dem Gerät liegen darf
Eine mobile Anwendung, die Offline-Daten hält, verarbeitet personenbezogene Daten im Sinne der DSGVO auf einem Endgerät, das nicht immer unter direkter Kontrolle der Verwaltung steht. Daraus ergeben sich konkrete Pflichten.
Art. 32 DSGVO verlangt angemessene technische und organisatorische Maßnahmen. Für eine Offline-App bedeutet das: lokale Verschlüsselung sensibler Daten (idealerweise über die Plattform-Keychain und den betriebssystem-eigenen Schutz), Bindung der lokalen Daten an eine erfolgreiche Anmeldung, automatische Löschung des lokalen Speichers bei Abmeldung oder wiederholter Fehlauthentifizierung, sowie Fernlösch-Funktion bei Geräteverlust (Wipe-Token, der beim nächsten Verbindungsaufbau ausgelöst wird).
Art. 5 Abs. 1 lit. c DSGVO verlangt Datenminimierung. Auf dem Gerät eines Hausmeisters hat nur das zu liegen, was für die aktuelle Route und die nächsten geplanten Aufgaben erforderlich ist — nicht der gesamte Bestand der Verwaltung. Ein Synchronisationsmodell, das standardmäßig den kompletten Datenbestand auf jedes Gerät lädt, ist datenschutzrechtlich nicht zu rechtfertigen.
Für die EXIF-Daten aus Fotos gilt dasselbe: GPS-Koordinaten, Gerätekennungen und Software-Versionen sind personen- und mindestens geräte-bezogen. Sie werden vor dem Upload entfernt, sofern nicht ein konkreter Zweck ihre Erhebung rechtfertigt — etwa die Dokumentation eines Schadensortes in einem weitläufigen Außenbereich, die dann aber ausdrücklich ausgewiesen wird.
Was eine Offline-First-App nicht leistet
Auch hier gilt das Prinzip der ehrlichen Abgrenzung. Ein Offline-First-System auf PWA-Basis leistet bewusst nicht folgendes:
- Echtzeit-Kollaboration offline. Wenn zwei Hausmeister in getrennten Funklöchern dasselbe Protokoll bearbeiten, sehen sie die Änderungen des jeweils anderen erst nach der Synchronisation. Ein Live-Cursor wie in einer kollaborativen Textverarbeitung ist offline ausgeschlossen.
- Push-Benachrichtigungen ohne Netz. Ein neuer Auftrag, der während der Offline-Phase zugewiesen wird, erreicht das Gerät erst beim nächsten Verbindungsaufbau. Dringende Benachrichtigungen — etwa für Havarien — gehören weiterhin in einen dedizierten Alarmierungsweg (Anruf, SMS).
- Unbegrenzte Offline-Dauer. Browser-Speicherquoten bewegen sich je nach Gerät und Betriebssystem zwischen wenigen hundert Megabyte und mehreren Gigabyte. Ein Hausmeister, der zehn Tage ohne Sync Fotos aufnimmt, wird irgendwann gegen die Quote laufen. Realistische Offline-Phasen sind Stunden bis einzelne Tage, nicht Wochen.
- Ersatz für rechtlich vorgeschriebene Prüfprotokolle. Die Pflicht zur Aufbewahrung von Prüfnachweisen nach BetrSichV, TrinkwV oder DGUV-Vorschriften bleibt unverändert. Eine Offline-App ist ein Erfassungswerkzeug, kein Archiv-System.
Wo wir stehen
Das Epic zur Offline-First-Mobile-Funktion in ImmoGenio ist beschlossen. Der Umsetzungsweg ist eine installierbare Progressive Web App auf der bestehenden Portal-Code-Basis, ergänzt um einen Service Worker für Anwendungs-Start ohne Netz, eine IndexedDB-gestützte Outbox, ein Operation-Log mit idempotenten Client-UUIDs und eine Konflikt-Resolver-Ansicht im Portal für den Fall, dass Feld-Änderungen auseinanderlaufen. Fotos werden vor dem Upload um EXIF-Geokoordinaten bereinigt und über signierte Upload-Intents direkt in den Objektspeicher geladen, ohne den API-Server als Durchleitungs-Engpass zu belasten. Signaturen werden auf dem Gerät erfasst, zusammen mit Geräte- und Client-Zeitstempel abgelegt und nach Annahme serverseitig mit einer unabhängigen Zeitmarke versehen.
Die Umsetzung ist in acht Teilaufgaben geschnitten, vom Sync-Schema im API-Backend über den Presigned-Upload-Pfad für Blobs bis zur Device-Matrix-Abnahme unter iOS Safari und Android Chrome mit Airplane-Mode-E2E-Tests. Eine spätere Portierung in eine nativ signierte Store-App über Capacitor ist bewusst offengehalten, wird aber erst angegangen, wenn ein Mandant sie aus Geräte-Management-Gründen verpflichtend fordert.
Was Sie nicht sehen werden: keine Doppelt-App für iOS und Android, keine vollautomatische Konfliktauflösung, keine unbegrenzte Offline-Phase. Was Sie sehen werden: ein Werkzeug, mit dem ein Hausmeister in einer Tiefgarage ein komplettes Übergabeprotokoll erstellen, Fotos anfügen und Unterschriften einholen kann — und das am Ende der Route, sobald das Gerät wieder Empfang hat, ohne Daumen-gedrückt-Moment synchronisiert.
Fragen, Rückmeldungen oder eigene Erfahrungen mit mobiler Erfassung ohne Netz im Hausverwaltungsbetrieb? Wir freuen uns über Ihre Nachricht an kontakt@immogenio.de.