myNextDays – React-Native-App für Ferienwohnung-Verwaltung

Wer mehrere Ferienwohnungen, Ferienhäuser oder ein kleines Hotel betreibt, arbeitet selten am Schreibtisch. Genau dafür haben wir myNextDays gebaut: eine native Ferienwohnung Verwaltung App für Android, die Buchungen, Belegungskalender, Gästenachrichten und Reinigungsaufgaben aufs Smartphone bringt. Die App ist das mobile Frontend einer Plattform aus Property-Management-System (PMS), Channel Manager und Direktbuchung. Anbieter ist die myNextDays ApS aus Bindslev in Dänemark, entwickelt hat die App unsere Agentur The Freelancer Marketing. Du findest sie als „myNextDays“ im Google Play Store.

In dieser Case Study zeigen wir dir, wie eine App für Ferienwohnungsverwaltung entsteht, wenn sie nicht als Insellösung, sondern als Teil eines bestehenden Systems gedacht wird. Zielgruppe sind Vermieter, Agenturen und Hotels, genauer: der Betrieb selbst und sein Team bis hin zur Reinigungskraft. Wir erklären die Ausgangslage, die Ziele und die Entscheidungen, die wir bewusst gegen naheliegende Features getroffen haben. In den folgenden Teilen geht es um Rollen, Kalender, Posteingang, Aufgaben, Architektur, Datenschutz und den Launch. Alle Zahlen stammen aus dem Code und der Git-Historie, Stand September 2026.

myNextDays auf einen Blick

Bevor wir ins Detail gehen, hier die Kurzfassung. myNextDays ist keine eigenständige App mit eigener Datenhaltung, sondern ein zweiter Zugang zum selben System, das Betriebe auch im Web-Dashboard nutzen. Die App spricht dieselbe Schnittstelle an, arbeitet auf demselben Datenbestand und enthält keine eigene Geschäftslogik. Preise, Beträge, Rechte und Statuswechsel entscheidet immer der Server. Das klingt unspektakulär, ist aber die wichtigste Architekturentscheidung des Projekts: Web und App können sich nie widersprechen, weil es nur eine Wahrheit gibt. Wenn du selbst eine App entwickeln lassen willst, die an ein bestehendes System andockt, ist dieser Grundsatz der erste, über den wir sprechen würden.

Projekt-Steckbrief

Zur Plattform gehören inzwischen drei Apps. Diese Case Study behandelt die Betriebs-App com.mynextdays.app. Eigentümer von Ferienobjekten haben seit dem 9. September 2026 eine eigene App, „myNextDays Eigentümer“. Eine dritte App für Gäste und den Marktplatz myBestDays ist in Vorbereitung und noch in keinem Store. Die Trennung war kein Plan vom ersten Tag an, sondern ist im Projekt gewachsen. Warum wir aus einer App mehrere gemacht haben, erklären wir im Abschnitt über die Architektur.

Was die App leistet

In drei Sätzen: Die App zeigt dem Betrieb morgens, wer anreist, wer abreist und was offen ist. Sie bündelt Buchungen und Belegung aller Objekte aus allen Kanälen in einem Kalender und beantwortet Gästenachrichten aus einem gemeinsamen Posteingang. Und sie gibt dem Reinigungsteam Aufgaben mit Checklisten und Fotonachweis in die Hand, ohne ihm Gastnamen oder Beträge zu zeigen.

Konkret umfasst die aktuelle Version diese Bereiche:

• Übersicht: Kennzahlen mit Zeitraum-Umschalter, Tageslisten für Anreisen, Abreisen und anwesende Gäste sowie Kacheln, die sich nach den Rechten des Nutzers richten.

• Belegungskalender: Monatsansicht für ein Objekt mit Tagespreisen und eine Matrix aller Objekte über viele Monate, mit fester Objektspalte und fester Datumsleiste.

• Buchungen: Liste mit Suche und Filtern, Detail-Panel mit Check-in, Check-out samt Rechnung, Storno, Zusatzleistungen und dem Annehmen oder Ablehnen von Buchungsanfragen.

• Posteingang: Nachrichten aus Portalen, Anfragen, Marktplatz, WhatsApp und dem Eigentümer-Chat in einer Liste, mit Vorlagen, KI-Vorschlag, Übersetzung, geplantem Senden und Anhängen.

• Aufgaben: Liste und Wochenkalender, Checklisten nach Räumen, Fotonachweis per Kamera oder Bildauswahl, Auslagen und Vertretungsanfragen.

• Inserate und Objekte: Objekte mit Status und Vertriebskanälen, Beschreibungen, mehrsprachige Gästemappe, Zusatzfelder und Teile der Objektkartei.

• Bewertungen, Konto und Sicherheit: Bewertungen beantworten, Zwei-Faktor-Authentifizierung einrichten, Sitzungen beenden und das Konto direkt in der App löschen.

Zahlen aus dem Projekt

Wir nennen hier nur, was wir gemessen haben. Nutzer- oder Umsatzzahlen gibt es an dieser Stelle bewusst nicht: Die App ist frisch im Store, und alle Beträge, die du auf unseren Screenshots siehst, stammen aus einem Vorführ-Mandanten mit Demo-Daten. Was sich belastbar zählen lässt, ist der Umfang der Arbeit selbst:

Zwei Zahlen verdienen einen Kommentar. Dass der native Eigencode nur 168 Zeilen umfasst, zeigt, wie weit man mit React Native auch ohne Expo kommt: Fast alles, von Kamera über Push bis Kryptografie, läuft über gepflegte Bibliotheken. Und die Tests konzentrieren sich auf die Logik in lib/, also dort, wo Fehler teuer werden: Token-Handling, Zugriffsrechte im Posteingang, Zeitzonen bei Aufgaben, Sortierungen und Kontolöschung. Oberflächen-Tests wie Snapshots oder End-to-End-Läufe gibt es nicht, darauf gehen wir im Qualitätsteil ehrlich ein. Wer hinter dem Projekt steht und wie wir arbeiten, liest du über Andy Staudinger.

Ausgangslage: Ferienvermietung zwischen Airbnb, Booking.com und Excel

Ferienvermietung ist ein Geschäft mit vielen Schnittstellen. Ein Objekt steht gleichzeitig bei Airbnb, Booking.com und Vrbo, manchmal zusätzlich auf einer eigenen Buchungswebsite. Jedes Portal hat seinen eigenen Kalender, seine eigenen Nachrichten, seine eigenen Fristen und seine eigene Logik für Anfragen und Bewertungen. Dazu kommen Reinigung, Schlüsselübergabe, Eigentümer, die informiert werden wollen, und die Buchhaltung. Viele Betriebe halten das mit einer Mischung aus Portal-Apps, Tabellen, Messenger-Gruppen und Erfahrung zusammen. Das funktioniert, solange es wenige Objekte sind. Ab einer gewissen Größe entstehen genau die Fehler, die in dieser Branche am meisten schaden: Doppelbuchungen, verpasste Anfragen und Reinigungen, die niemand zugeteilt hat.

Der Alltag von Gastgebern und Verwaltern mit mehreren Objekten

Ein typischer Tag eines Ferienwohnungsverwalters beginnt nicht mit einer Auswertung, sondern mit Fragen: Wer reist heute an, wer ab? Ist die Wohnung nach der Abreise gestern Abend gereinigt? Hat der Gast von Booking.com auf die Frage nach dem Parkplatz geantwortet? Läuft bei Airbnb eine Buchungsanfrage, die bis heute Mittag beantwortet sein muss? Jede dieser Fragen hat ihre Antwort in einem anderen System. Wer fünf, zehn oder zwanzig Einheiten betreut, springt ständig zwischen Portal-Apps und Tabellen hin und her. Der Aufwand steigt nicht linear mit der Zahl der Objekte, sondern mit der Zahl der Kombinationen aus Objekt, Kanal und Person.

Hinzu kommt das Team. In größeren Betrieben arbeiten Verwalter, Mitarbeiter im Service und externe Reinigungskräfte an denselben Objekten, aber mit sehr unterschiedlichen Bedürfnissen. Die Reinigungskraft braucht die Aufgabe, die Checkliste und den Zeitpunkt, aber weder den Namen des Gasts noch den Buchungsbetrag. Der Verwalter braucht beides, dazu die Nachrichten und den Stand der Aufgaben. Und der Eigentümer der Wohnung möchte wissen, wie belegt sein Objekt ist und was er ausgezahlt bekommt. In einer Messenger-Gruppe oder einer geteilten Tabelle lassen sich diese Sichtweisen kaum sauber trennen. Genau hier beginnt der Bedarf an einer Ferienwohnung Verwaltung App mit echtem Rollenmodell.

Die zweite Quelle für Fehler sind die Kalender selbst. Eine Überbuchung entsteht, wenn zwei Kanäle dasselbe Objekt für denselben Zeitraum verkaufen, weil einer den anderen nicht rechtzeitig kennt. Wer das per Hand verhindern will, pflegt Sperrzeiten in mehreren Portalen parallel. Wer das automatisch lösen will, braucht einen Channel Manager, der Verfügbarkeit und Preise zentral hält und an die Portale verteilt. myNextDays setzt dafür laut Produktdokumentation auf einen Multi-Kalender je Unterkunft als einzige Wahrheit über alle Kanäle. Die App muss diese Wahrheit mobil sichtbar machen, ohne selbst eine zweite zu erzeugen.

Warum der Desktop allein nicht reicht

Die meisten Verwaltungssysteme für Ferienwohnungen sind im Kern Web-Anwendungen. Das ist sinnvoll, denn Stammdaten, Preisregeln, Automationen und Abrechnungen bearbeitet man am besten auf einem großen Bildschirm. Das Tagesgeschäft passiert aber woanders: bei der Schlüsselübergabe vor Ort, im Auto zwischen zwei Objekten, in der Wohnung während der Reinigung oder abends auf dem Sofa, wenn eine Gästenachricht eintrifft. Ein responsives Web-Dashboard auf dem Smartphone hilft dabei nur bedingt. Es kennt keine Push-Benachrichtigungen im Hintergrund, keinen direkten Kamerazugriff für den Fotonachweis und keine Anmeldedaten, die sicher im Schlüsselbund des Geräts liegen.

Deshalb ist die Frage nicht „Web oder App“, sondern „was gehört wohin“. Eine gute App für Ferienwohnungsverwaltung übernimmt die Momente, in denen du unterwegs bist und schnell handeln musst: eine Anfrage annehmen, einen Gast einchecken, eine Nachricht beantworten, eine Aufgabe abhaken, ein Foto als Nachweis hochladen. Sie muss dafür nicht alles können, was das Web kann. Sie muss aber das, was sie kann, schneller und zuverlässiger erledigen als der Browser auf dem Telefon. Diese Abgrenzung zieht sich durch das ganze Projekt und ist der Grund, warum bestimmte Funktionen bewusst im Web geblieben sind.

• Anreise und Abreise: Check-in und Check-out passieren am Objekt, oft mit Rechnung und Zahlart direkt beim Gast.

• Reinigung: Checklisten und Fotos entstehen in der Wohnung, nicht im Büro.

• Gästekommunikation: Anfragen bei Airbnb haben Fristen, die das Portal setzt. Wer sie verpasst, verliert die Buchung.

• Kurzfristige Änderungen: Stornos, Verschiebungen und Vertretungen im Team lassen sich nicht auf den nächsten Bürotag schieben.

Marktumfeld und die Lücke für myNextDays

Der Markt für Ferienvermietungssoftware ist gut besetzt, und das ist kein Nachteil. Anbieter wie Smoobu aus Berlin, das im DACH-Raum sehr verbreitet ist und eigene Apps für iOS und Android anbietet, Lodgify mit einer Mobile-App und einer separaten App für Reinigungskräfte, Hostaway mit Owner Portal und gemeinsamem Posteingang, Guesty mit Unified Inbox und Beds24 haben über Jahre gezeigt, was Gastgeber brauchen. Sie haben Muster etabliert, an die sich Nutzer gewöhnt haben: den Belegungsplan mit fester Objektspalte, die Tagesübersicht mit Anreisen und Abreisen, den gemeinsamen Posteingang für alle Portale. Für uns war dieses Marktumfeld vor allem eine Referenz für bewährte Strukturen.

Das merkt man im Code. An mehreren Stellen verweisen Kommentare ausdrücklich auf solche Vorbilder, etwa beim Buchungsreiter der Übersicht, bei der Matrix des Kalenders oder bei der Objektdetailseite. Das ist keine Kooperation mit diesen Anbietern und auch kein Nachbau, sondern die bewusste Entscheidung, Nutzer nicht mit neuen Bedienmustern zu überraschen, wo sich bewährte längst durchgesetzt haben. Wer vorher mit einem anderen Tool gearbeitet hat, soll sich in myNextDays schnell zurechtfinden. Die eigenen Akzente setzt die App an anderer Stelle.

Die Positionierung von myNextDays ergibt sich aus der Plattform, nicht aus einem Feature-Vergleich:

• Ein System für mehrere Vertriebswege: PMS, Channel Manager, Direktbuchungs-Website und der eigene Marktplatz myBestDays teilen sich einen Datenbestand.

• Europäischer Anbieter mit EU-Hosting: myNextDays ApS sitzt in Dänemark, Datenbank und API laufen self-hosted bei Hetzner in der EU.

• Ohne Tracking: In der App steckt kein Analytics-, Werbe- oder Crash-SDK. Das Privacy Manifest meldet für keine Datenart Tracking.

• Rollen bis zur Reinigung: Dieselbe App dient Verwaltern und Reinigungskräften, aber mit strikt getrennten Sichten, die der Server vorgibt.

• Ferienwohnung und Hotel: Das Modell ist nicht auf einen Betriebstyp festgelegt, was sich schon an den Demo-Mandanten für eine Ferienvermietung und ein Hotel zeigt.

Ob diese Kombination im Markt trägt, entscheidet sich nicht in einer Case Study, sondern bei den Betrieben, die das System nutzen. Unsere Aufgabe war, die Plattform mobil so umzusetzen, dass sie ihre Stärken auch unterwegs ausspielt. Eine Ferienwohnung Verwaltung App, die auf demselben Datenmodell arbeitet wie das Web, die Rechte des Servers respektiert und ohne Tracking auskommt, ist dafür die Grundlage.

Ziele und Anforderungen an die App

Am Anfang stand keine Feature-Liste, sondern eine Frage: Was muss ein Betrieb unterwegs erledigen können, damit er seltener an den Rechner muss? Daraus haben wir die Anforderungen abgeleitet und iterativ umgesetzt. Die erste Version entstand im Juni 2026 als einzelne App, die mehrere Zielgruppen gleichzeitig bediente. Bis zur Einreichung bei Google Play Ende August wurde daraus eine fokussierte Betriebs-App. Wenn du selbst vor einem solchen Projekt stehst, lohnt sich ein Blick in unseren Leitfaden zur MVP-Entwicklung Schritt für Schritt, denn viele der Entscheidungen hier folgen genau diesem Prinzip: erst den Kern stabil machen, dann erweitern.

Geschäftsziele

Aus Sicht des Anbieters sollte die App den Zugang zur bestehenden Plattform erweitern, ohne ein zweites Produkt zu erzeugen, das eigens gepflegt werden muss. Daraus ergeben sich die zentralen Anforderungen, die sich im Code wiederfinden:

• Eine Schnittstelle, ein Datenbestand: Die App nutzt dieselbe API wie das Web-Dashboard. Neue Fachlogik entsteht im Backend und steht damit beiden Oberflächen zur Verfügung.

• Gleiche Anmeldung wie im Web: Login, Zwei-Faktor-Authentifizierung und Rechte sind dieselben. Wer im Web ein Konto hat, kann sich sofort in der App anmelden.

• Store-tauglich von Anfang an: Kontolöschung in der App, Datenschutzangaben, Anbieterangaben und minimale Berechtigungen waren Pflicht, keine Nacharbeit.

• Keine Abo-Logik in der App: Das Abonnement läuft außerhalb der App. Die App ist im Store kostenlos und verkauft nichts.

• Wartbar für eine kleine Mannschaft: Code, der in mehreren Apps gleich sein muss, wird per CI-Prüfung byte-identisch gehalten, statt ihn an drei Stellen separat zu pflegen.

Gerade der erste Punkt ist wichtiger, als er klingt. Viele Apps für Ferienwohnungsverwaltung starten als eigenes Projekt mit eigener Logik, etwa weil die mobile Entwicklung von einem anderen Team kommt. Nach einem Jahr rechnen Web und App dann Preise leicht unterschiedlich, zeigen Rechte unterschiedlich an oder kennen unterschiedliche Status. In myNextDays ist das ausgeschlossen: Wenn der Server einen Betrag nicht liefert, weil der Nutzer ihn nicht sehen darf, zeigt die App einen Strich an und nie eine erfundene Null. Wenn der Server keinen Tagespreis kennt, bleibt die Kalenderzelle leer.

Ziele je Zielgruppe

Die App kennt mehrere Rollen, und jede hat eigene Ziele. Welche Oberfläche jemand sieht, entscheidet die App an genau einer Stelle anhand der Rolle und der Rechte, die der Server nach dem Login meldet. Unbekannte Rollen führen nicht in eine Standardansicht, sondern zurück zum Login. Freigeschaltet wird clientseitig nichts.

Für den Betrieb ist das Ziel Geschwindigkeit: Die häufigsten Handgriffe, also Anfrage beantworten, einchecken, auschecken mit Rechnung und Nachricht senden, sollen mit wenigen Tipps erledigt sein. Für das Team ist das Ziel Klarheit: Jede Person sieht, was sie heute erledigen muss, und kann den Status selbst melden. Für die Reinigung ist das Ziel Einfachheit und Datensparsamkeit. Sie bekommt eine reduzierte Oberfläche mit genau zwei sichtbaren Bereichen, und die Finanz- und Vertriebsbereiche sind für sie nicht nur ausgeblendet, sondern gar nicht erst registriert.

Die Eigentümer haben wir bewusst herausgelöst. Bis zum 9. September 2026 enthielt die Betriebs-App ein komplettes Eigentümer-Erlebnis mit sieben Screens. Seitdem liegt es ausschließlich in der eigenen App „myNextDays Eigentümer“. Meldet sich ein Eigentümer in der Betriebs-App an, erklärt ein Hinweis die Lage und öffnet die Eigentümer-App oder, falls sie fehlt, den Store-Eintrag. Umgekehrt fängt die Eigentümer-App Verwaltungskonten ab. In der Betriebs-App bleibt nur die Sicht der Agentur auf ihre Eigentümer, etwa Eigentümer-Aufenthalte, eine Kachel mit offenen Eigentümer-Vorgängen und der Eigentümer-Chat im Posteingang.

Bewusste Nicht-Ziele

Genauso wichtig wie die Ziele waren die Dinge, die die App ausdrücklich nicht leisten soll. Jede dieser Entscheidungen hat eine Begründung, und keine davon ist ein Zufall:

• Kein Tracking und keine Analytics: Die App enthält kein Analytics-, Werbe- oder Crash-SDK. Von Firebase sind nur die Basis und der Push-Dienst eingebunden. Für Abstürze gibt es einen eigenen, anonymen Meldeweg ohne Token. Damit bleibt die Datensicherheitsangabe im Store kurz und ehrlich, und es braucht keinen Tracking-Dialog.

• Kein Klon des Web-Dashboards: Automationen, KI-Einstellungen und Sprachen sind in der App nur lesbar. Automationen mit Auslöser und Zeitversatz auf dem Telefon zu bearbeiten, würde Fehleingaben begünstigen, die dann an echte Gäste gehen. Auch Rich-Text-Formatierungen der Gästemappe bearbeitet man besser im Web; die App warnt, bevor Formatierungen verloren gehen.

• Kein Offline-Modus: Die App hält keine lokale Datenbank und keinen Cache. Ohne Netz zeigen die Screens einen klaren Fehlerzustand mit „Wiederholen“, statt veraltete oder erfundene Daten anzuzeigen. In einem System mit mehreren Kanälen wäre ein lokaler Stand, der vom Server abweicht, gefährlicher als eine ehrliche Fehlermeldung. Offline lesbar sind nur die gesetzlichen Anbieterangaben.

• Keine Käufe in der App: Die App verkauft kein Abo und enthält keinen Kauf-Link. Das Abonnement läuft außerhalb. Zusatzleistungen, die in der App gebucht werden, sind reale Leistungen zwischen Betrieb und Gast, keine digitalen Güter.

• Keine Registrierung in der App: Ein neuer Betrieb wird im Web angelegt, der Link in der App öffnet den Browser. Die In-App-Registrierung haben wir am 19.08.2026 entfernt.

• Keine mehrsprachige Oberfläche, vorerst: Die App-Oberfläche ist auf Deutsch. Mehrsprachig sind die Texte für Gäste, etwa die Gästemappe auf Deutsch, Englisch und Dänisch.

Eine App wird nicht besser, weil sie alles kann, was das Web kann. Sie wird besser, wenn sie genau die Handgriffe übernimmt, für die man sonst zum Rechner müsste, und den Rest bewusst dort lässt.

Nicht-Ziele schützen ein Projekt vor Ausuferung und machen es gegenüber dem Auftraggeber planbar. Sie sind auch ein gutes Werkzeug gegen Store-Probleme: Jede zusätzliche Berechtigung, jedes zusätzliche SDK und jede Kauf-Funktion bringt eigene Prüfregeln bei Google und Apple mit sich. Dass die App auf Android nur Internet, Benachrichtigungen und Kamera anfordert und die Kamera nur beim Fotonachweis braucht, ist eine direkte Folge dieser Abgrenzung.

PMS, Channel Manager und Direktbuchung: das System hinter der App

Um zu verstehen, was die App zeigt, hilft ein kurzer Blick auf das System dahinter. myNextDays ist eine Plattform für Ferienvermietung mit einem Property-Management-System als Kern. Daran hängen ein Channel Manager, der Buchungen und Verfügbarkeit mit Portalen wie Booking.com, Airbnb, Vrbo und Expedia abgleicht, eine Direktbuchungs-Website und der eigene Marktplatz unter der Marke myBestDays. Die App bildet diese Welt nicht nach, sondern macht sie auf dem Smartphone bedienbar. Deshalb findest du in fast jedem Screen Spuren aller drei Bausteine: Kanalfarben im Kalender, Kanalmarken in der Buchungsliste, Vertriebskanäle bei den Inseraten.

PMS vs. Channel Manager kurz erklärt

Die Begriffe werden oft vermischt, beschreiben aber unterschiedliche Aufgaben. Ein Channel Manager kümmert sich um alles vor der Buchung: Er verteilt Verfügbarkeit und Preise an die Portale und holt deren Buchungen zurück, damit ein Objekt nicht doppelt verkauft wird. Ein PMS kümmert sich um alles rund um die Buchung und danach: Gäste, Kommunikation, Check-in, Reinigung, Rechnungen und Abrechnungen mit Eigentümern. In der Praxis brauchen Betriebe beides, und die Frage ist, ob beides in einem System steckt oder über eine Schnittstelle zusammenarbeitet.

In myNextDays sind beide Funktionen integriert. Die Anbindung an die Portale läuft über einen angebundenen Channel-Manager-Dienst im Backend. Nach außen spricht die App schlicht von „Portalen“, weil das für Gastgeber der verständliche Begriff ist. Für die App bedeutet das: Sie muss nicht wissen, wie eine Buchung von Booking.com technisch hereinkommt. Sie bekommt vom Server eine Buchung mit Kanal, Status und Beträgen und stellt sie dar. Der Tagespreis im Kalender kommt ebenfalls vom Server, der ihn aus dynamischen Preisen, Ausnahmen, Wochentagspreisen und dem Grundpreis ermittelt.

Einige Regeln der Portale schlagen trotzdem bis in die Oberfläche durch. Bei Buchungsanfragen von Airbnb etwa kommt die Antwortfrist ausschließlich vom Portal; fehlt sie, zeigt die App keinen erfundenen Countdown. Für Ablehnungen bietet sie nur die vier Gründe an, die Airbnb erlaubt. Solche Details sind der Unterschied zwischen einer App, die mit Portalen zusammenarbeitet, und einer, die nur so aussieht. Mehr dazu im Teil über Buchungen und den Posteingang.

Direktbuchung und das Portal myBestDays

Neben den großen Portalen gibt es bei myNextDays zwei eigene Vertriebswege: die Direktbuchungs-Website des Betriebs und den Marktplatz myBestDays. In der App tauchen sie überall dort auf, wo Kanäle eine Rolle spielen. Der Kalender unterscheidet Buchungen farblich nach „Direkt“, „Website“, „myBestDays“, Booking.com, Airbnb, Vrbo und „Anderes Portal“, und die Legende wird aus derselben Liste erzeugt, damit Farbe und Beschriftung nie auseinanderlaufen. Bei den Inseraten zeigt jedes Objekt drei Vertriebskanäle, nämlich Website, Plattform und Portale, jeweils mit Zustand: aktiv, pausiert, nicht eingerichtet oder fehlerhaft, beim Marktplatz zusätzlich in Prüfung.

• Eigene Texte für den Marktplatz: Neben der allgemeinen Objektbeschreibung pflegt der Betrieb eine eigene Beschreibung für myBestDays, beide sind in der App bearbeitbar.

• Nachrichten aus dem Marktplatz: Konversationen von myBestDays erscheinen im selben Posteingang wie die der Portale, klar gekennzeichnet.

• Bewertungen aus allen Kanälen: Marktplatz-Bewertungen auf einer Skala von 1 bis 5 und Portal-Bewertungen auf einer Skala von 0 bis 10 stehen in einer Liste und lassen sich beantworten.

• Zusatzleistungen: Gebuchte Extras erscheinen im Buchungsdetail mit Zahlstatus; die Beträge rechnet das Backend.

Eine eigene App für Gäste und den Marktplatz ist als dritte App der Plattform angelegt, aber noch Vorarbeit und in keinem Store. Für diese Case Study zählt deshalb nur, wie die Betriebs-App mit Direktbuchungen umgeht: Sie behandelt sie gleichberechtigt neben Portal-Buchungen. Für einen Verwalter ist das entscheidend, weil eine provisionsfreie Direktbuchung im Kalender genauso sichtbar sein muss wie eine Buchung von Airbnb, sonst entsteht an genau dieser Stelle wieder das Risiko einer Überbuchung.

Was mobil sein muss und was im Web bleibt

Die Trennlinie zwischen App und Web haben wir nicht nach technischer Machbarkeit gezogen, sondern nach Nutzungssituation und Risiko. Grundsätzlich gilt: Alles, was unterwegs schnell gehen muss, gehört in die App. Alles, was selten passiert, viel Eingabe braucht oder bei einem Fehler großen Schaden anrichtet, bleibt in der Web-App für das Verwaltungssystem. Die folgende Übersicht zeigt, wie das im Projekt konkret aussieht:

Die Objektkartei ist das beste Beispiel für diese Abwägung. Im Web führt ein Assistent in neun Stufen durch alle Informationen zu einem Objekt. Die App bietet fünf davon an, und zwar genau die, die man vor Ort braucht: Abläufe, Zugang, Handwerker, Marketing und Hausmappe. Stufe 1 fehlt absichtlich. Sie enthält die IBAN, die dänische Personennummer und die Steuernummer des Eigentümers, und diese Daten sollen nicht auf einem Gerät stehen, das bei einem Kundentermin auf dem Tisch liegt. Die App lädt diese Daten gar nicht erst, statt sie nur auszublenden.

Ähnlich klar ist die Linie bei den Automationen im Posteingang. Vorlagen und Wissensfakten darfst du in der App bearbeiten, weil ein Tippfehler dort sofort sichtbar ist und nur eine Antwort betrifft. Automationen mit Auslöser und zeitlichem Versatz schicken dagegen Nachrichten an viele Gäste, oft Tage später. Ein Fehler, der auf dem kleinen Bildschirm übersehen wird, landet dann bei echten Gästen. Deshalb zeigt die App diese Einstellungen an, damit du weißt, was läuft, bearbeitet werden sie aber im Web. Diese Art der Abwägung, Funktion für Funktion, macht aus einer Ferienwohnung Verwaltung App ein Werkzeug, dem man im Alltag vertraut.

Mit diesem Systemverständnis im Hinterkopf schauen wir uns im nächsten Teil an, wie die App Rollen und Rechte umsetzt, wie der Belegungskalender auch bei vielen Objekten flüssig bleibt und wie Buchungen, Inserate und Bewertungen auf dem Smartphone funktionieren.

Rollenmodell: Betrieb, Team, Reinigung und Eigentümer

Eine Ferienwohnung Verwaltung App wird nicht von einer Person benutzt, sondern von einem ganzen Betrieb. Die Inhaberin einer Agentur braucht Umsatz, Buchungen und Gästenachrichten. Die Reinigungskraft braucht ihre Aufgaben für heute und eine Checkliste, aber auf keinen Fall die Beträge einer Buchung oder den vollen Namen des Gasts. Wer ein Rollenmodell erst spät in ein Projekt einzieht, baut am Ende eine App, in der Menüpunkte „irgendwie“ ausgeblendet werden. Bei myNextDays haben wir die Frage „Wer sieht was?“ deshalb früh beantwortet und an genau einer Stelle im Code verankert. Alles, was die App anzeigt, leitet sich aus dem ab, was der Server über das angemeldete Konto sagt.

Das klingt selbstverständlich, ist es in der Praxis aber selten. Viele mobile Apps prüfen Rollen verstreut in einzelnen Screens, mit dem Ergebnis, dass eine neue Rolle oder eine geänderte Berechtigung an zehn Stellen nachgezogen werden muss und an der elften vergessen wird. Für eine Plattform, die gleichzeitig Ferienhausvermieter, Agenturen mit Team und kleine Hotels bedient, wäre das ein dauerhaftes Risiko. Die folgenden Abschnitte zeigen, wie die Betriebs-App die Oberfläche umschaltet, warum die eigentliche Absicherung trotzdem im Backend liegt und warum Eigentümer heute eine eigene App bekommen.

Rollen und Berechtigungen

Das System kennt sechs Rollen: admin, co_admin, owner, staff, cleaner und shift_lead. Sie stammen aus dem Typ Role in contexts/AuthContext.tsx und entsprechen den Rollen, die das Backend in das Anmelde-Token schreibt. Welche Oberfläche daraus in der App wird, zeigt die Tabelle. Maßgeblich für die Tab-Leiste ist dabei nicht der Rollenname, sondern ob das Konto die Berechtigung manage_tasks besitzt.

Wichtig ist die zweite Zeile der Mitarbeiter-Rollen: Reinigungskräfte bekommen die Finanz- und Vertriebsbereiche laut Code-Kommentar „GAR NICHT (nicht nur versteckt)“. Die Screens für Buchungen oder Posteingang sind für diese Rollen gar nicht erst registriert. Ein Tipp auf einen versteckten Knopf oder ein manipulierter Deep-Link führt deshalb nicht in einen Bereich, den die Person nicht sehen soll. Für Verwalter bleiben es bewusst fünf sichtbare Tabs. Aufgaben, Inserate, Bewertungen und Profil sind registriert, haben aber keinen eigenen Tab-Button und sind über „Mehr“ erreichbar. So bleibt die Leiste auf einem kleinen Display lesbar.

Innerhalb der Screens greift eine zweite, feinere Ebene. Die Übersicht zeigt Nachrichten-Kennzahlen nur mit pm_chat, Eigentümer-Vorgänge nur mit approve_block und Teamaufgaben nur mit manage_tasks. Im Posteingang entscheidet inbox_reply, ob überhaupt ein Antwortfeld erscheint, und inbox_assign, ob Vorgänge zugewiesen werden dürfen. Ein neues Objekt anlegen darf nur, wer Objekteinstellungen verwalten darf. Fehlt eine Berechtigung, fragt die App den entsprechenden Endpunkt gar nicht erst ab, statt eine Fehlermeldung „Zugriff verweigert“ anzuzeigen. Für die Person sieht das aufgeräumt aus, für den Server bedeutet es weniger unnötige Anfragen.

Wie die App die Rolle erkennt

Direkt nach dem Login lädt die App GET /auth/me. Die Antwort enthält die Rolle, die Listen capabilities und permissions, die Mandanten-ID und ein Kennzeichen, ob es sich um ein Vorführkonto handelt. Name und Avatar holt die App einmal pro Sitzung zusätzlich über /auth/account, allerdings nur auf Best-Effort-Basis: Scheitert dieser Abruf, funktioniert die App trotzdem. Die Rolle selbst kommt ausschließlich vom Server. Es gibt keinen Schalter, keine lokale Einstellung und keinen Zwischenspeicher, über den ein Gerät sich eine andere Rolle „geben“ könnte.

Aus dieser Antwort leitet lib/experience.ts mit der Funktion experienceFor(me) das Ziel-Erlebnis ab. Die Datei ist bewusst klein: eine Tabelle BY_ROLE, die jeder Rolle eine Start-Route zuordnet, und eine Funktion, die nachschlägt. Admin und Co-Admin landen in den Tabs mit der Übersicht, Mitarbeiter in denselben Tabs mit reduziertem Satz, Eigentümer auf dem Hinweis-Screen. Welche Tabs im Navigator erscheinen, entscheidet anschließend navigation/HostTabs.tsx mit einer einzigen Prüfung: can(me, "manage_tasks").

Die Funktion can() in lib/permissions.ts spiegelt die Logik der Web-Navigation. Ein Admin darf alles. Jede andere Rolle muss die gefragte Berechtigung in der Vereinigung aus capabilities und permissions haben, so wie der Server sie geliefert hat. Web und App treffen damit dieselbe Entscheidung auf derselben Datengrundlage. Wenn der Betrieb im Web-Dashboard einer Mitarbeiterin mehr Rechte gibt, sieht sie diese nach dem nächsten Laden von /auth/me auch in der App, ohne App-Update.

Der interessanteste Fall ist der, den man nicht erwartet: eine Rolle, die die App nicht kennt, oder ein Konto ganz ohne Rolle. Hier gibt experienceFor() null zurück, und App.tsx meldet das Konto ab. Die App fällt nie auf das Agentur-Dashboard als Standard zurück. Dieses Prinzip heißt fail-closed: Im Zweifel wird der Zugang geschlossen, nicht geöffnet. Für den Eigentümer haben wir dagegen bewusst einen eigenen Hinweis-Screen gebaut statt null, denn ein stummer Logout wäre für ihn nicht von „Passwort falsch“ zu unterscheiden.

„Kein clientseitiges Aufmachen – die Rolle kommt ausschließlich vom Server.“ Kommentar im Kopf von lib/experience.ts

Rechte serverseitig durchsetzen

Alles bisher Beschriebene betrifft die Oberfläche. Eine Oberfläche ist aber keine Sicherheitsgrenze. Wer ein Token besitzt, kann die API auch ohne App ansprechen. Deshalb gilt bei myNextDays: Die App entscheidet, was sie zeigt, der Server entscheidet, was sie bekommt. Die Betriebs-App enthält keine eigene Fachlogik. Sie spricht dieselbe FastAPI-Schnittstelle /api/v1 an wie das Web-Dashboard und arbeitet auf demselben Datenbestand. Der Kopfkommentar von lib/api.ts fasst das in einem Satz zusammen: Die Business-Logik bleibt im Backend, die App ruft nur HTTP.

Darunter liegt eine selbst gehostete Supabase-Instanz mit Postgres. Die Plattform ist mandantenfähig, jeder Betrieb ist ein eigener Mandant. Der Mandant steckt im JWT, und Row Level Security in Postgres filtert Zeilen auf Datenbankebene. Das greift auch bei Realtime: Die App setzt ihr Token, bevor sie einen Kanal abonniert, damit die Datenbank beim Verbindungsaufbau nur Änderungen des eigenen Mandanten ausliefert. Die Projektregeln gehen aber einen Schritt weiter und halten ausdrücklich fest, dass RLS allein nicht reicht. Zusätzlich prüft die API Rolle und Berechtigung, bevor sie Daten ausliefert.

Ein gutes Beispiel ist die Maskierung. Darf ein Konto keine Beträge sehen, liefert der Server total_amount = null. Die App zeigt dann „—“ und niemals eine 0, denn eine 0 wäre eine falsche Aussage. Ohne das Recht auf volle Gastnamen kommt nur der Vorname an. Die App füllt an keiner Stelle etwas auf oder rät. Wenn du so ein System planst, lohnt sich ein Blick auf unsere Datenbank-Entwicklung mit Postgres und die Backend- und API-Entwicklung: Die meisten Fehler bei Rollen und Mandanten entstehen nicht in der App, sondern im Datenmodell darunter.

• Oberfläche: Tabs und Kacheln nach Berechtigung aus /auth/me, zentral in experience.ts und permissions.ts.

• Navigation: Geschützte Routen existieren nur mit Session. Ein Deep-Link auf eine geschützte Route wird im ausgeloggten Zustand ignoriert.

• API: FastAPI prüft Rolle und Berechtigung pro Endpunkt und maskiert Felder wie Beträge oder Kontaktdaten.

• Datenbank: Row Level Security filtert auf den Mandanten, auch für Realtime-Abos.

Eigentümer: warum eine eigene App

Bis zum 9. September 2026 enthielt die Betriebs-App ein vollständiges Eigentümer-Erlebnis mit sieben Screens für Objekte, Kalender, Einnahmen, Statistik, Anfragen, Objektdetail und Fotoalbum. Technisch funktionierte das. Konzeptionell passte es nicht: Ein Eigentümer, der seine Ferienwohnung von einer Agentur vermieten lässt, ist kein Mitarbeiter des Betriebs. Er erwartet eine andere Sprache, andere Inhalte und einen eigenen Eintrag im Store. Außerdem wuchs sein Bereich weiter, mit Auszahlungen, Abrechnungen, Sperranträgen, Zählerständen und einem Chat mit der Agentur.

Wir haben den Eigentümer-Bereich deshalb vollständig in die separate App „myNextDays Eigentümer“ (com.mynextdays.owner) ausgebaut. Sie trägt dieselbe Markenfarbe, ist also keine eigene Marke, sondern ein eigenes Werkzeug. In der Betriebs-App sieht ein Eigentümer-Konto heute nur noch den Screen OwnerAppHinweis: eine kurze Erklärung, ein Knopf, der per mynextdaysowner:// in die Eigentümer-App springt oder, falls sie fehlt, in den Store, und ein Knopf zum Abmelden. Umgekehrt fängt die Eigentümer-App ein Verwaltungskonto mit einem eigenen Screen ab.

Was in der Betriebs-App bleibt, ist die Sicht der Agentur auf ihre Eigentümer: Eigentümer-Aufenthalte werden in Buchungslisten und Kalender gekennzeichnet und zählen nicht als Umsatz. Offene Vorgänge wie Sperranträge erscheinen in der Übersicht als Kachel „Eigentümer-Vorgänge“, sofern das Konto sie freigeben darf. Und der Chat mit Eigentümern läuft auf Agenturseite im gemeinsamen Posteingang. Der Play-Store-Text der Betriebs-App beschreibt stellenweise noch den alten Eigentümer-Bereich, die Release-Notes sagen dagegen korrekt, dass das Eigentümer-Portal in eine eigene App umgezogen ist.

Ferienwohnung und Hotel in einem Modell

myNextDays richtet sich an Ferienhaus- und Ferienwohnungsvermieter, an Agenturen und an Hotels. In der App zeigt sich das nicht als getrennte Produkte, sondern als ein gemeinsames Objektmodell. Jede vermietbare Einheit ist ein Objekt mit einem Typ. Die Typ-Liste in lib/properties.ts spiegelt die des Webs und reicht von Ferienhaus, Appartement, Glamping, Tiny House, Stellplatz und Hausboot bis zu Einzelzimmer, Doppelzimmer, Zweibettzimmer, Familienzimmer, Junior Suite und Suite. Ein Hotelzimmer taucht damit im Kalender, in der Buchungsliste und bei den Inseraten genauso auf wie ein Strandhaus.

Für die Präsentation des Systems gibt es entsprechend mehrere Vorführ-Mandanten: einen Ferienvermieter mit acht Objekten und ein Hotel mit zwölf Zimmern. Auch die Ausstattungsliste enthält hotelübliche Merkmale wie Zimmerreinigung oder Frühstück im Zimmer, generiert aus denselben Texten wie das Web. Wir behaupten damit nicht, dass die App ein vollwertiges Hotel-PMS mit Kasse oder Frühstücksplanung ist. Der Punkt ist ein anderer: Weil Rollen, Kalender und Buchungen nicht an „Ferienwohnung“ hängen, sondern an „Objekt“, muss ein kleiner Hotelbetrieb keine zweite App lernen. Für eine Hotel-PMS-App auf Deutsch im kleinen Maßstab ist das ein tragfähiger Ausgangspunkt.

Die Übersicht: Anreisen, Abreisen und der Tag auf einen Blick

Die Übersicht am Abend: 2 Anreisen, 1 Abreise, 7 Gäste im Haus, dazu 14 Anfragen, die auf Freigabe warten, und 57 offene Konversationen. Darunter die Buchungskarten mit Kanal-Kennzeichnung wie Vrbo oder Direkt. Alle Objekte, Gäste und Zahlen sind Demo-Daten des Vorführ-Mandanten.

Der Screen, den ein Verwalter nach dem Öffnen der App sieht, heißt schlicht „Übersicht“ (screens/HostDashboard.tsx). Er ist dem Web-Dashboard nachempfunden, aber nicht einfach verkleinert. Oben steht eine Begrüßung nach Tageszeit, „Guten Morgen“, „Guten Tag“ oder „Guten Abend“, bewusst ohne Vornamen, weil /auth/me keinen liefert und die App keinen erfinden soll. Direkt darunter folgt die Zeile, die für viele Gastgeber die wichtigste des Tages ist: wie viele Gäste heute ankommen, wie viele abreisen und wie viele gerade im Haus sind.

Was morgens zuerst zählt

Wer mehrere Ferienwohnungen verwaltet, beginnt den Tag selten mit einer Umsatzkurve. Die ersten Fragen sind operativ: Wer reist heute an, und ist die Wohnung bis dahin gereinigt? Wer reist ab, und wann kann die Reinigung rein? Wer ist gerade im Haus und könnte sich melden? Die App beantwortet diese Fragen mit einer Liste mit Reitern statt mit fünf gestapelten Blöcken. Die Chips „Anreisen“, „Abreisen“ und „Im Haus“ schalten zwischen den Tageslisten um, dazu kommt „Anstehend“ für das, was in den nächsten Tagen passiert. Das spart auf einem 6-Zoll-Display viel Scrollen.

Die Komponente dafür heißt BuchungsReiter.tsx, ein Kommentar nennt Lodgify als Vorbild für das Muster. Jede Zeile ist eine Buchungskarte mit Foto, Objekt, Gast, Zeitraum und Kanal. Ein Tipp öffnet das Buchungsdetail als Panel von rechts, dasselbe Panel wie aus Kalender und Buchungsliste. Wichtig ist der Status „Im Haus“: Er wird nicht aus dem Datum geschlossen, sondern ist der tatsächlich gespeicherte Check-in-Zustand. Ein Gast, dessen Anreisetag heute ist, der aber noch nicht eingecheckt wurde, erscheint daher nicht fälschlich als anwesend. Eigentümer-Aufenthalte zählen als Check-in, aber nicht als Umsatz.

Unterhalb der Tageslisten folgt ein Kennzahlen-Block mit vier Werten und einem einzigen Zeitraum-Umschalter für 7 Tage, 30 Tage, 3 Monate oder 12 Monate. Dazu kommt eine Verlaufskurve, die wir ohne Chart-Bibliothek direkt mit SVG gezeichnet haben, und Trendpfeile mit Prozentwert. Kacheln mit Beträgen wie Umsatz oder Umsatz je Buchung erscheinen nur, wenn der Server für dieses Konto überhaupt Beträge liefert. Wer keine Finanzrechte hat, sieht also keine leeren Kacheln mit Strichen, sondern gar keine.

Handlungsbedarf statt Kennzahlen-Wand

Viele Dashboards verwechseln Information mit Handlungsbedarf. Eine Übersicht mit zwanzig Kennzahlen sieht beeindruckend aus, sagt aber nicht, was als Nächstes zu tun ist. Wir haben deshalb Hinweiszeilen über die Listen gesetzt, die genau das beantworten. Im Screenshot sind es „14 Anfragen warten auf Freigabe“ und „57 offene Konversationen“. Die erste Zahl stammt aus dem Dashboard-Endpunkt /reservations/dashboard und meint Buchungsanfragen, die der Betrieb annehmen oder ablehnen muss. Die zweite kommt aus /inbox/unread-count und führt direkt in den Posteingang.

„Freigabe nötig“ steht bewusst nicht als weiterer Reiter in der Tagesliste. Offene Anfragen sind eine Aufgabe, keine Tagesinformation, und sie sollen nicht zwischen Anreisen und Abreisen untergehen. Je nach Berechtigung kommen weitere Kacheln dazu: Mit approve_block erscheinen die Eigentümer-Vorgänge, mit manage_tasks der Stand der Teamaufgaben, mit pm_chat Nachrichten-Kennzahlen wie gesendet, empfangen, automatisiert und Tagesschnitt. Eine Rolle ohne diese Rechte sieht die Kacheln nicht, und die App fragt die Daten auch nicht an.

1. Hinweise: Anfragen mit Freigabebedarf und offene Konversationen, jeweils mit Sprung an die richtige Stelle.

2. Tageslisten: Anreisen, Abreisen, Im Haus und Anstehend als Reiter in einer Liste.

3. Vorgänge: Eigentümer-Vorgänge und Teamaufgaben, nur für Rollen, die sie bearbeiten dürfen.

4. Kennzahlen: vier Werte mit einem Zeitraum-Umschalter und Verlaufskurve, Beträge nur mit Recht.

Ein Detail, das man erst bemerkt, wenn es fehlt: Die Übersicht hat keinen Demo-Fallback. Lade-, Fehler- und Leerzustand sind getrennt. Ist das Backend nicht erreichbar, steht genau das auf dem Bildschirm, mit einem Knopf „Wiederholen“. Eine App, die bei einem Serverproblem schöne Beispielzahlen einblendet, wäre für einen Betrieb gefährlicher als eine, die ehrlich sagt, dass gerade keine Daten da sind. Einen Offline-Modus mit lokal gespeicherten Buchungen gibt es in der App nicht, das ist eine bewusste Entscheidung für eine einzige, aktuelle Datenquelle.

Aktualität: Pull-to-Refresh und Realtime

Eine Übersicht ist nur so gut wie ihre Aktualität. Wenn eine Buchung über ein Portal hereinkommt, während der Verwalter die App offen hat, soll sie ohne Zutun erscheinen. Die Übersicht abonniert dafür über Supabase Realtime die Tabellen, die ihre Zahlen speisen: Buchungen und Objekte, dazu die Aufgaben, aber nur für Rollen, die die Teamaufgaben-Kachel überhaupt sehen. Ändert sich dort etwas, lädt die App die Übersicht gebündelt neu, mit 400 Millisekunden Verzögerung wie im Web. So erzeugen zehn schnelle Änderungen hintereinander nur einen Abruf. Ein Polling, also ein Nachfragen im festen Takt, gibt es nicht.

Bemerkenswert ist, was nicht abonniert wird. Die Kalenderverfügbarkeit etwa speist keine Zahl der Übersicht. Ein Abo darauf würde bei jeder Kalendersperre die ganze Übersicht neu laden, ohne dass sich etwas Sichtbares ändert. Für Tabellen, die serverseitig für direkte Lesezugriffe gesperrt sind, wie die Nachrichten, gibt es ebenfalls kein Abo. Für diese Fälle und für alle Situationen, in denen eine Verbindung abgerissen ist, bleibt Pull-to-Refresh: Nach unten ziehen lädt die Übersicht vollständig neu. Insgesamt haben zehn Screens der App diese Geste.

Belegungskalender: Einzel- und Multi-Kalender auf dem Smartphone

Der Belegungskalender ist das Herz jeder Software für Ferienvermietung. Er beantwortet die Frage, die Gäste, Portale und Reinigung gleichermaßen stellen: Ist die Einheit frei? In der myNextDays-App steckt er in screens/HostCalendar.tsx, mit rund 1.400 Zeilen einer der größten Screens. Er bietet zwei Ansichten, die sich über ein Icon im Kopf umschalten lassen: eine Monatsansicht für ein einzelnes Objekt und eine Matrix für alle Objekte gleichzeitig. Beide lesen dieselben Daten, nämlich die Verfügbarkeit mit Tagespreisen aus /calendar/availability und die Buchungen aus /reservations.

Der Multi-Kalender: jedes Objekt eine Zeile, jeder Tag eine Spalte mit Tagespreis. Die Buchungsbalken sind nach Kanal eingefärbt, der heutige Tag ist rot markiert. Objekte, Preise und Buchungen sind Demo-Daten des Vorführ-Mandanten.

Einzelansicht je Objekt

Die Monatsansicht ist für den Blick auf eine Wohnung gedacht, etwa wenn ein Gast anruft und fragt, ob das Strandhaus Ende Mai noch frei ist. Oben wählt ein Dropdown das Objekt. Darunter stehen vier Monate untereinander, jeder als klassisches Raster mit sieben Spalten. Jede Zelle zeigt die Tageszahl und den Tagespreis, belegte Tage tragen einen farbigen Balken mit dem Namen des Gasts. Die Datenlogik liegt in lib/calendar-grid.ts. Sie teilt Buchungen, die über einen Wochenwechsel laufen, in Segmente, damit ein Balken am Sonntag endet und am Montag in der nächsten Zeile weiterläuft.

Der Tagespreis wird nicht in der App berechnet. Er kommt fertig vom Server, der ihn nach einer festen Rangfolge auflöst: dynamischer Preis vor manuellem Override vor Wochentagspreis vor Grundpreis. Gibt es keinen Preis, bleibt die Zelle leer. Die App zeigt keinen geschätzten oder zuletzt bekannten Wert. Auch die Währung kommt aus den Daten, konkret aus der Objektwährung. Fehlt sie, erscheint die reine Zahl ohne Symbol, statt ein Euro-Zeichen anzunehmen, das bei einem dänischen Ferienhaus falsch wäre.

Multi-Kalender für viele Einheiten

Sobald ein Betrieb mehr als zwei, drei Objekte hat, reicht die Monatsansicht nicht mehr. Dann braucht es den Belegungsplan, den man aus Hotel-PMS und Channel-Manager-Software kennt: Objekte als Zeilen, Tage als Spalten. In der App heißt diese Ansicht MatrixCalendar, ihre Logik liegt in lib/calendar-matrix.ts. Die Zeitachse reicht zwei Monate zurück und vierzehn Monate voraus und lässt sich horizontal durchwischen. Die Objektspalte links und die Datumsleiste oben bleiben dabei stehen, ein Muster, das laut Code-Kommentar von Lodgify und Hostaway inspiriert ist. Die Objektspalte lässt sich einklappen, dann zeigt sie nur Fotos und gibt mehr Platz für Tage frei. Ein Knopf „Heute“ springt zurück zum aktuellen Datum.

Auf dem Smartphone ist die eigentliche Herausforderung die Leistung. Ein Kommentar im Code rechnet es vor: Bei sechzehn Monaten Achse und zwanzig Objekten wären es über 9.000 Zellen, und die Ansicht wäre beim ersten Wischen eingefroren. Wir rendern deshalb nur das sichtbare Fenster plus einen Puffer von zwölf Spalten (SPALTEN_PUFFER). Die Tagesdaten laden in Blöcken zu 45 Tagen (BLOCK_TAGE) nach, sobald man in einen neuen Bereich wischt. Das Muster haben wir aus dem Web-Kalender übernommen, wo es als Overscan bekannt ist. Das Ergebnis ist eine Matrix, die sich auch mit vielen Einheiten flüssig bedienen lässt.

Ein zweites Detail betrifft die Darstellung von Wechseltagen. Reist ein Gast am Samstag ab und der nächste am selben Samstag an, würden zwei ganztägige Balken wie eine Doppelbelegung aussehen. Die Balken beginnen deshalb in der Mitte des Anreisetags und enden in der Mitte des Abreisetags. So stehen zwei Buchungen am Wechseltag sichtbar nebeneinander, ohne sich zu überlappen. Bei der Umstellung fiel übrigens ein unsichtbarer Standardabstand von 12 Pixeln im UI-Kit auf, der jede Spalte breiter machte als berechnet und so alle Buchungen gegenüber den Datumsspalten verschob. Solche Fehler findet man nur, wenn man den Kalender mit echten Datenmengen auf echten Geräten testet.

Die Farben stammen aus einer einzigen Liste in lib/calendar-channels.ts, aus der auch die Legende erzeugt wird. Früher trug die Legende eigene Farbwerte und kannte zwei Kanäle nicht. Seit der Umstellung kann es keinen Balken mehr ohne passenden Legendeneintrag geben. Ein Tipp auf einen Balken öffnet das Buchungsdetail. Bis August 2026 waren die Balken reine Farbflächen ohne Aktion. Für Reinigungskräfte ist der Belegungskalender übrigens gar nicht vorhanden. Sie sehen stattdessen einen eigenen Aufgaben-Kalender, der ohne Gastnamen und Beträge auskommt.

Doppelbuchungen vermeiden: ein Kalender als einzige Wahrheit

Die häufigste Frage von Vermietern, die auf mehreren Portalen inserieren, lautet: Wie vermeide ich Doppelbuchungen bei Airbnb und Booking.com? Die Antwort von myNextDays ist architektonisch: Es gibt pro Unterkunft genau einen Kalender, und der ist die einzige Wahrheit. Jede Buchung, egal ob sie über ein Portal, die eigene Website, den Marktplatz oder direkt am Telefon entsteht, landet in diesem Kalender. Von dort aus verteilt der Channel Manager der Plattform Verfügbarkeit und Preise an die angebundenen Portale. So steht ein Tag, der auf Vrbo gebucht wurde, auch auf Booking.com und Airbnb nicht mehr zur Verfügung.

Wichtig für das Verständnis: Diese Synchronisation passiert nicht in der App. Die App ist ein Fenster auf den zentralen Kalender, sie liest ihn und zeigt Änderungen in Echtzeit an, weil sie die speisenden Tabellen über Realtime abonniert. Wenn um 23 Uhr eine Buchung über ein Portal eingeht, sieht der Verwalter sie im offenen Kalender, ohne neu zu laden. Das Verteilen an die Portale übernimmt das Backend über den Channel Manager. Für Demo-Daten ist dieser Weg übrigens hart abgeschaltet: Buchungen des Vorführ-Mandanten werden ohne Portal-Anbindung angelegt, sodass aus einer Vorführung nie etwas an ein echtes Portal gelangt.

Für dich als Betreiber heißt das: Die Qualität einer Channel-Manager-App hängt weniger an der mobilen Oberfläche als an der Frage, ob es wirklich nur einen Kalender gibt. Systeme, die pro Portal eigene Kalender führen und diese per iCal abgleichen, haben systembedingte Verzögerungen, in denen eine Doppelbuchung entstehen kann. Die App kann das nicht reparieren, sie kann es nur sichtbar machen. Deshalb haben wir den Aufwand in eine saubere Darstellung gesteckt: Wechseltage als Halbtage, Kanäle eindeutig eingefärbt, Eigentümer-Aufenthalte als Sperre gekennzeichnet.

Buchungen, Inserate und Bewertungen

Neben Übersicht und Kalender sind es drei Bereiche, die in einer App für Ferienwohnungsverwaltung täglich gebraucht werden: die Buchungen selbst, die Inserate, also die Objekte mit ihren Vertriebskanälen, und die Bewertungen der Gäste. In myNextDays sind die Buchungen ein eigener Tab. Inserate und Bewertungen liegen unter „Mehr“, weil sie seltener geöffnet werden. Alle drei greifen auf dieselben Endpunkte zu wie das Web-Dashboard, sodass eine Änderung am Handy sofort auch am Schreibtisch sichtbar ist.

Buchungsliste, Filter und Detail

Die Buchungsliste mit Suche nach Buchungsreferenz oder Gast, den Filtern Alle, Bestätigt, Angefragt und Storniert und der Sortierung „Anstehend zuerst“. Die Karte zeigt die Herkunft, hier Booking.com. Gäste, Zeiträume und Beträge sind Demo-Daten.

Die Buchungsliste (screens/HostReservations.tsx) beginnt mit einem Suchfeld „Nach Buchungsref. oder Gast suchen“. Darunter liegen Filter-Chips für den Status, nämlich Alle, Bestätigt, Angefragt und Storniert, sowie Filter für Kanal und Objekt. Jede Karte hat links ein großes Objektfoto, oben ein Status-Badge und unten die Kanal-Marke. Rechts stehen Zeitraum, Buchungsreferenz, Objekt, Gast mit Anzahl der Gäste und der Preis. Für Booking.com, Airbnb und Vrbo zeigt die Marke das Logo des Portals als Herkunftsangabe, andere Kanäle einen Punkt in der Kanalfarbe. Portalcodes erscheinen als Klarname.

Die Status-Badges haben feste Bedeutungsfarben: Angefragt in Amber, Bestätigt in Grün, Im Haus in Blau, Abgeschlossen in Grau und Storniert in Rot. Spannender ist die Sortierung. Ursprünglich sortierte die Liste nach Anreisedatum, neueste zuerst. Beim Test mit dem Vorführ-Mandanten öffnete sie bei 546 Buchungen mit einer Anreise im Jahr 2027, und die heutigen Gäste lagen irgendwo weit unten. Seitdem gibt es in lib/buchungs-reihenfolge.ts zwei benannte Reihenfolgen: „Anstehend zuerst“ zeigt, was noch nicht abgereist ist, mit der nächsten Anreise oben. „Zuletzt gebucht zuerst“ sortiert nach dem Buchungszeitpunkt, den das Portal geliefert hat, nicht nach dem Zeitpunkt, zu dem unser Server die Buchung gespeichert hat.

Das Buchungsdetail öffnet sich als Panel, das von rechts einfährt, egal ob man aus dem Kalender, der Liste oder der Übersicht kommt. Es schließt per Knopf, per Wisch nach rechts, per Tipp auf die abgedunkelte Fläche oder mit der Android-Zurück-Taste. Die Logik dahinter haben wir aus dem Web portiert und mit einem Realtime-Abo auf genau diese Buchung versehen: Nimmt eine Kollegin am Schreibtisch parallel eine Änderung vor, sieht man sie im offenen Panel. Über einen Deep-Link lässt sich eine Buchung auch direkt aus einer Push-Meldung öffnen.

• Einchecken: vor dem Anreisetag nur mit Rückfrage, damit niemand versehentlich einen Gast einen Tag zu früh als anwesend markiert.

• Check-out mit Rechnung: erst ab dem Abreisetag. Eine Zahlart-Auswahl legt fest, ob die Rechnung als bezahlt (bar oder Karte) oder als offene Rechnung abgeschlossen wird. Danach zeigt das Panel die Rechnungsnummer.

• Anfragen annehmen oder ablehnen: für Buchungsanfragen, etwa das Modell „Request to Book“ bei Airbnb.

• Stornieren und Nachricht an den Gast, die direkt in den passenden Posteingang-Thread springt.

Alle Aktionen sind gegen Doppeltipp gesperrt. Das ist kein Nebenschauplatz: Auf einem Smartphone mit wackeliger Verbindung tippen Menschen ein zweites Mal, wenn nicht sofort etwas passiert. Ohne Sperre entstünden zwei Check-outs oder zwei Rechnungen.

Buchungsdetail: Gast, Preise, Zahlungen, Zusatzleistungen

Unter den Aktionen gliedert sich das Detail in aufklappbare Abschnitte: „Preis & Rechnung“ mit Gesamtbetrag, bereits bezahltem Betrag und offenem Rest, „Zusatzleistungen“, „Gast“, „Angaben des Portals“ und „Notiz“. Aufklappen statt endlos scrollen ist hier eine bewusste Entscheidung, denn eine Buchung mit Portalbedingungen, Zusatzleistungen und Kontaktdaten würde sonst mehrere Bildschirmhöhen füllen. Die Typdefinition des Buchungsdetails in lib/reservations.ts bildet seit August 2026 den vollständigen Vertrag des Backends ab. Vorher fehlten dort einige Felder, und ein fehlendes Feld ist in TypeScript kein Kompilierfehler, sondern eine unsichtbare Lücke in der Oberfläche.

Bei Geld gilt eine klare Regel: Die App rechnet nicht, sie zeigt an. Gesamtbeträge, offene Posten und Zusatzleistungen berechnet das Backend. Die App formatiert die gelieferten Werte mit lib/currency.ts, und zwar bewusst ohne Intl.NumberFormat, weil die JavaScript-Engine Hermes auf iOS kein vollständiges Intl mitbringt. Stattdessen gibt es eine eigene, deterministische Formatierung mit Tausenderpunkt, Dezimalkomma und kuratierten Symbolen für Euro, Dollar, Pfund, Franken, die skandinavischen Kronen, Złoty und Tschechische Kronen. Unbekannte ISO-Codes werden als Suffix angehängt, etwa „1.200 PLN“. Ohne Währung steht die reine Zahl da, nie ein erfundenes Euro-Zeichen. Ohne Betragsrecht steht „—“.

Buchbare Zusatzleistungen eines Objekts verwaltet ZusatzleistungenBlock.tsx. Er zeigt die gekauften Positionen mit Zahlstatus und bietet eine Schnellauswahl aus dem Katalog des Objekts. Menge ändern, als bezahlt markieren und stornieren geht direkt am Handy. Storno und Rücknahme verlangen einen Grund, damit im Protokoll des Vorgangs nachvollziehbar bleibt, warum eine Position weggefallen ist. Eine vollständige Zeitleiste der Buchung zeigt die App nicht, das Protokoll liegt serverseitig.

Inserate, Beschreibung, Gästemappe und Zusatzfelder

Die Inserate: acht Objekte mit Status „Live“ und je drei Kanal-Chips für Website, Plattform und Portale. Ein farbiger Punkt zeigt, ob der Kanal aktiv, pausiert, nicht eingerichtet oder fehlerhaft ist. Alle Objekte sind Demo-Daten des Vorführ-Mandanten.

Der Screen „Inserate“ (HostListings.tsx) zeigt die echten Objekte des Betriebs mit Lebenszyklus-Status, Objekttyp und Ort. Jedes Objekt trägt drei Chips für die Vertriebskanäle: Website für die eigene Direktbuchungsseite, Plattform für den Marktplatz myBestDays und Portale für die über den Channel Manager angebundenen Buchungsportale. Der Zustand je Kanal wird als Ampelpunkt dargestellt, also aktiv, pausiert, nicht eingerichtet oder Fehler, beim Marktplatz zusätzlich ein Wartezustand. So sieht ein Verwalter auf einen Blick, ob ein neues Objekt schon überall vermarktet wird oder ob irgendwo eine Anbindung hakt.

Was fehlt, fehlt bewusst: Die Inseratsliste zeigt keine Bewertungs- oder Belegungszahlen, weil der zugrunde liegende Endpunkt sie für diesen Pfad nicht liefert. Wir hätten sie aus anderen Quellen zusammenrechnen können, aber dann hätte die App eine zweite Wahrheit neben dem Server gehabt. Neue Objekte lassen sich mit einem Kurzbogen direkt vor Ort anlegen, mit Name, Art, Gästezahl und Adresse. Pflicht ist nur der Name. Das Objekt entsteht als Entwurf und wird am Schreibtisch vervollständigt, etwa nach der Erstbesichtigung einer Ferienwohnung, deren Eigentümer gerade unterschrieben hat.

Das Objektdetail (PropertyDetail.tsx) zeigt Foto, Name, Nummer, Adresse, Kernmerkmale, Ausstattung und Kanäle. Die deutschen Ausstattungs-Bezeichnungen werden per Skript aus den Übersetzungen des Webs generiert, damit App und Web nie unterschiedliche Begriffe verwenden. Die Beschreibung hat einen Lesemodus mit „Mehr anzeigen“ und „Kopieren“ und einen Bearbeitungsmodus, der bei ungespeicherten Änderungen nachfragt. Es gibt genau zwei Texte: die allgemeine Beschreibung und eine optionale eigene Beschreibung für den Marktplatz.

Die Gästemappe ist der Ort für alles, was Gäste vor und während des Aufenthalts brauchen, etwa Anfahrt, Schlüsselübergabe oder WLAN. Sie besteht aus acht Blöcken und ist als einziger Teil der App mehrsprachig, mit einem Sprachumschalter für Deutsch, Englisch und Dänisch. Die App-Oberfläche selbst ist nur auf Deutsch. Im Web werden die Texte in einem Rich-Text-Editor gepflegt. Die App zeigt sie als Klartext, wandelt beim Speichern zurück und warnt vorher, dass Fettschrift, Kursivschrift und Links dabei verloren gehen. Zusatzfelder, also frei definierte Objektangaben, zeigt die App vollständig an, leere als „—“, bearbeitbar nur mit dem Recht zur Objektverwaltung.

Auch die Objektkartei mit Prozess, Zugang, Handwerkern, Marketing und Hausmappe ist mobil erreichbar, allerdings nur mit fünf der neun Stufen aus dem Web. Weggelassen ist ausgerechnet die erste, und das mit Absicht: Sie enthält Bankverbindung, Personennummer und Steuernummer des Eigentümers. Diese Daten sollen nicht auf einem Gerät stehen, das beim Kundentermin offen auf dem Tisch liegt.

Bewertungen lesen und beantworten

Bewertungen (HostReviews.tsx) kommen aus zwei Welten mit unterschiedlichen Skalen: vom Marktplatz myBestDays mit einer Skala von 1 bis 5 und von den Portalen mit einer Skala von 0 bis 10. Die App führt beide in einer Liste zusammen und zeigt Sterne auf Basis eines vom Server normierten Werts. Hat eine Bewertung keine Note, zeigt die App keine Sterne, statt eine Note zu erfinden. Unter jeder Bewertung steht ein Antwortfeld, sodass ein Verwalter eine Gästebewertung direkt vom Handy aus beantworten kann, etwa auf dem Weg zur nächsten Übergabe.

Neue Marktplatz-Bewertungen erscheinen per Realtime ohne Neuladen. Portal-Bewertungen werden beim Öffnen und per Pull-to-Refresh aktualisiert, weil ihre Tabelle serverseitig für direkte Lesezugriffe gesperrt ist. Weil der Vorführ-Mandant keine Bewertungen hat, gibt es von diesem Screen übrigens keinen Store-Screenshot. Wir zeigen lieber keinen Screen als einen mit gestellten Kundenstimmen.

Direktbuchungen neben Portal-Buchungen

Portale bringen Reichweite, kosten aber Provision. Deshalb setzen viele Vermieter parallel auf Direktbuchungen, sei es über eine eigene Website oder über Stammgäste, die anrufen. myNextDays behandelt beide Wege gleichwertig. Im Kalender und in der Buchungsliste unterscheidet die App fein: „Direkt“ für Buchungen, die der Betrieb selbst anlegt, „Website“ für Buchungen über die Direktbuchungs-Website und „myBestDays“ für den Marktplatz der Plattform. Direkt und Website sind beide provisionsfrei, werden aber getrennt ausgewiesen und bewusst in zwei deutlich unterschiedlichen Farbtönen eingefärbt, damit man sie im Balken auseinanderhalten kann.

Für die tägliche Arbeit ist entscheidend, dass eine Direktbuchung keine Sonderbehandlung braucht. Sie erscheint in derselben Übersicht, im selben Kalender und in derselben Liste wie eine Buchung von Booking.com, Airbnb oder Vrbo, mit denselben Aktionen für Check-in, Check-out und Rechnung. Und sie sperrt den Tag im zentralen Kalender, sodass der Channel Manager ihn auf allen Portalen schließt. Genau das unterscheidet eine integrierte Ferienwohnung Verwaltung App von der Kombination aus Portal-Apps und Tabelle, mit der viele Betriebe starten.

Aus Entwicklersicht war der wichtigste Baustein dafür die Kanal-Kette: ein Aufzählungstyp für Kanäle im Backend, eine zentrale Liste mit Bezeichnung und Farbe in der App und daraus abgeleitet alles, was im UI erscheint. Kommt ein neuer Kanal hinzu, etwa die eigene Website, reicht ein Eintrag an einer Stelle, und Kalender, Legende und Buchungskarten ziehen mit. Wie dieses Zusammenspiel im Web-Dashboard aussieht, beschreiben wir im Kontext unserer Web-Applikationen. Im nächsten Teil geht es um den Posteingang, die Aufgaben für die Reinigung und die Gestaltung der App.

Posteingang: Gästenachrichten aus Airbnb, Booking.com und Vrbo an einem Ort

Wer mehrere Ferienwohnungen über mehrere Portale vermietet, kennt das Muster: Eine Frage zum Schlüssel kommt über Airbnb, eine Rückfrage zur Anreisezeit über Booking.com, eine Stornobitte über Vrbo, und dazwischen schreibt noch der Eigentümer. Jedes Portal hat seine eigene App, seine eigenen Benachrichtigungen und seine eigene Logik. Der Posteingang ist deshalb für uns der Teil der Ferienwohnung Verwaltung App, an dem sich am deutlichsten zeigt, ob mobile Verwaltung im Alltag funktioniert. In screens/HostInbox.tsx – mit 1.429 Zeilen die größte Datei der App – laufen alle Gesprächsquellen in einer einzigen Liste zusammen.

Der Posteingang mit Suche, Filter-Knopf und Threads aus mehreren Portalen: Kanal-Badge am Avatar, Objekt und Anreisedatum unter dem Namen, roter Punkt für Ungelesenes. Alle Namen, Objekte und Nachrichten sind Demo-Daten des Vorführ-Mandanten „Nordlicht Ferienvermietung“.

Warum ein gemeinsamer Posteingang Antwortzeiten verkürzt

Antwortzeit ist auf den Portalen kein weiches Qualitätsmerkmal, sondern hat handfeste Folgen. Bei einer Airbnb-Buchungsanfrage („Request to Book“) läuft eine Frist, nach deren Ablauf das Portal die Anfrage selbst ablehnt. Wer seine Nachrichten auf drei Apps verteilt hat, verliert genau hier Zeit: Man muss erst wissen, wo die Nachricht liegt, bevor man antworten kann. Ein gemeinsamer Posteingang – im Englischen oft „Unified Inbox“ genannt – beseitigt diesen Suchschritt. Du öffnest eine Liste, siehst oben das zuletzt Aktive und antwortest aus derselben Oberfläche, egal über welchen Kanal der Gast geschrieben hat.

Wichtig war uns dabei die Sortierung. Die Liste ordnet nach letzte_aktivitaet, also nach dem Zeitpunkt, den das Portal selbst meldet, und nicht nach dem Zeitpunkt, an dem unser Server den Datensatz zuletzt angefasst hat. Das klingt nach einem Detail, verhindert aber einen typischen Fehler: Ein nächtlicher Synchronisationslauf würde sonst alte Gespräche nach oben spülen, und die wirklich neue Frage rutscht aus dem Blick. Fehlt der Portal-Zeitpunkt, bleibt die Zeitangabe leer, statt einen plausiblen, aber falschen Wert zu zeigen.

Neben den Portalbuchungen führt der Posteingang weitere Quellen, jeweils am Präfix der Thread-Kennung unterscheidbar:

Für die Arbeit mit vielen Threads gibt es eine Suche über Gastname, Objekt und Buchungscode sowie ein Filter-Sheet, das Filter und Sortierung in einem Bottom Sheet bündelt: Kanal, nur ungelesene, nur zugewiesene, Favoriten und als Alternative die Sortierung nach Anreisedatum. Im Kopf der Liste steht bewusst nur ein Knopf mit der Zahl der gesetzten Filter und ein kurzer Text daneben, was gerade eingrenzt. Eine Reihe von Filter-Chips über der Liste hätte auf einem schmalen Display den Platz gefressen, den die Nachrichten brauchen.

Threads, Kanal-Kennzeichnung und Bezug zur Buchung

Jede Zeile der Liste folgt demselben Aufbau: links ein runder Avatar mit den Initialen des Gasts, unten rechts daran ein kleines Kanal-Badge mit dem Anfangsbuchstaben des Kanals in dessen Farbe – A für Airbnb, B für Booking.com, V für Vrbo. Rechts daneben stehen Name, Buchungsstatus als Chip, die relative Zeit, darunter Objekt und Anreisedatum und schließlich eine zweizeilige Vorschau der letzten Nachricht. Ungelesene Threads tragen einen Punkt in der Akzentfarbe und eine kräftigere Vorschau. Die Kanalfarben kommen aus derselben Liste, aus der auch der Belegungskalender seine Balken färbt, sodass Airbnb in der ganzen App gleich aussieht.

Die Zuordnung ist dabei streng. Ein Portal ohne eigenen Kanalwert – Expedia, Agoda oder etwas Unbekanntes – landet als „Anderes Portal“ und wird nicht stillschweigend zur Direktbuchung erklärt. Der Eigentümer-Chat bekommt eine neutrale Farbe statt eines Portal-Abzeichens, denn er ist kein Vertriebskanal, und ein Airbnb-ähnliches Badge würde eine Buchungsquelle vortäuschen. Reine Bildnachrichten erscheinen in der Vorschau als „Foto“ statt als technisches Kürzel.

Ehrlich zur Einordnung: In der Screenshot-Runde vom 30.08.2026 fiel auf, dass Buchungsstatus, die der Server als new oder modified liefert, im Posteingang noch als englisches Rohwort erscheinen. Die deutschen Labels decken bisher „Bestätigt“, „Angefragt“, „Storniert“ und „Abgeschlossen“ ab. Das ist als offener Befund dokumentiert und auf dem Screenshot oben zu sehen.

Der Bezug zur Buchung ist nicht nur Beschriftung. Hat ein Thread eine verknüpfte Reservierung, öffnet ein Tipp im Gespräch dasselbe Buchungspanel, das auch Kalender, Buchungsliste und Übersicht verwenden – mit Zeitraum, Status, Preis und Aktionen. Umgekehrt springt „Nachricht an den Gast“ im Buchungsdetail direkt in den passenden Thread. Beide Richtungen nutzen dieselbe Komponente, damit es keine zweite, stiller veraltende Darstellung derselben Buchung gibt.

Im geöffneten Gespräch stehen die Werkzeuge hinter einem „+“-Knopf, wie man ihn von Messengern kennt:

• Vorlagen einfügen, die serverseitig für den konkreten Thread mit Platzhaltern gefüllt werden.

• KI-Vorschlag für eine Antwort – nur in Buchungs-Threads und im Eigentümer-Chat, nicht in jeder Quelle.

• Übersetzen einer Gastnachricht auf Knopfdruck. Die Übersetzung ist eine Lesehilfe und wird nicht gespeichert; das Original des Gasts bleibt die Quelle.

• Geplantes Senden mit Schnellzeiten wie „in einer Stunde“, „heute Abend“ oder „morgen früh“, bewusst ohne Datumspicker.

• Anhänge anzeigen und hochladen (JPG, PNG, WebP, GIF, PDF), mit Größenprüfung vor dem Upload.

Portal-Anfragen stehen nicht im Verlauf, sondern als eigene Karte darüber, weil sie eine Entscheidung mit Frist sind und kein Gespräch. Die Frist kommt ausschließlich vom Portal; liefert es keine, zeigt die App keinen erfundenen Countdown. Für die Ablehnung gibt es genau die vier Gründe, die Airbnb zulässt. Weitere Vorgangsaktionen – zuweisen, interne Notiz, Merker, Snooze, Archiv, Papierkorb – liegen in einem eigenen Sheet. Wer Vorlagen und Wissensfakten pflegen darf, kann sie mobil ändern; Automationen und KI-Einstellungen sind dagegen nur lesbar, weil eine falsch gesetzte Trigger-Verschiebung auf dem Telefon direkt bei echten Gästen ankäme.

Welche dieser Aktionen jemand sieht, entscheidet das Rechtemodell. lib/inbox-access.ts spiegelt die Regeln aus Web und API mit inbox_view_all, inbox_reply, inbox_assign und inbox_manage_config. Ohne Antwortrecht erscheint schlicht kein Eingabefeld. Die Maskierung von Feldern übernimmt der Server, die App hängt nur Aktionen an Rechte.

Eine bewusste Entscheidung betrifft die Aktualität: Der Posteingang nutzt kein Realtime. Die speisenden Tabellen sind seit Migration 0337 für angemeldete Clients gesperrt, um den Datenzugriff eng zu halten. Die Liste lädt beim Öffnen, nach dem Senden und per Pull-to-Refresh neu. Eigene Antworten erscheinen sofort (optimistisch) und werden zurückgenommen, falls der Server sie ablehnt – mit sichtbarer Meldung statt stillem Verschwinden.

Push-Benachrichtigungen mit Firebase Cloud Messaging

Damit du nicht ständig in den Posteingang schauen musst, meldet sich die App per Push. Technisch läuft das über Firebase Cloud Messaging (FCM) mit @react-native-firebase/messaging. Nach dem Login registriert die App ihr Gerätetoken beim Backend und kennzeichnet es mit der App-Kennung mynextdays. Diese Kennung ist mehr als Buchhaltung: Seit es eine eigene Eigentümer-App gibt, routet der Server Meldungen je Kategorie an die zuständige App. Eine Meldung für die Verwaltung landet so nicht auf dem Telefon eines Eigentümers und umgekehrt.

Was im Push steht, ist bewusst knapp. Der Text einer Benachrichtigung ist im Sperrbildschirm lesbar, ohne dass jemand das Gerät entsperrt. Deshalb gilt im Backend die Regel: keine Gastnamen und keine Beträge in der Meldung, nur das Ereignis. Im Datenteil steht ein Zielpfad mit der ID, etwa /reservierungen/{id}, /aufgaben/{id} oder /posteingang/{id}. Die eigentlichen Inhalte holt die App erst nach der Anmeldung über die API. Diese Disziplin ist im Versand-Dispatcher des Servers festgehalten; technisch erzwungen wird sie nicht, sie ist eine Pflicht des Aufrufers, die dort eingehalten wird.

Tippt man auf eine Meldung, bildet zielAlsDeepLink den Server-Pfad auf einen App-Link ab – aus posteingang im Web wird inbox in der App. Unbekannte Pfade ergeben bewusst nichts: Die App öffnet dann normal, statt auf einen geratenen Screen zu springen. Das funktioniert, wenn die App im Hintergrund lag, und ebenso nach einem Kaltstart über getInitialNotification – der häufigste Fall bei einer Nachricht, die nachts kam.

Hinter dem unscheinbaren Push steckten einige Fallstricke, die wir erst im Betrieb gefunden haben:

• Ab Android 13 verwirft das System jede Meldung still, wenn die Berechtigung POST_NOTIFICATIONS fehlt – FCM meldet dem Server trotzdem „zugestellt“. Die App fragt deshalb zur Laufzeit und gibt den echten Zustand zurück, statt eine Attrappe anzuzeigen.

• Auf iOS fehlte zeitweise das aps-environment-Entitlement, wodurch keine Meldung ankam. Die Ursache steht heute beim Namen im Protokoll, statt in einem generischen Fehler zu verschwinden.

• Der Benachrichtigungskanal nextdays_wichtig wird nativ angelegt. Angezeigt werden Meldungen im Hintergrund vom Betriebssystem selbst; eine zusätzliche Anzeige-Bibliothek brauchen wir nicht.

• Firebase wird erst bei Bedarf per require geladen, damit ein Firebase-Fehler nicht den App-Start mitreißt.

• Beim Logout meldet pushAbmelden() das Gerät ab, bevor das Token verworfen wird. Sonst bekäme das Telefon weiter Meldungen des abgemeldeten Betriebs – sichtbar im Sperrbildschirm für den nächsten Nutzer.

Welche Ereignisse genau einen Push auslösen, entscheidet der Server anhand der Kategorie und der Benachrichtigungseinstellungen des Nutzers. Die App empfängt generisch und springt ans Ziel. Im Vordergrund zeigt sie absichtlich keine Meldung.

Verschlüsselung ehrlich erklärt

Beim Eigentümer-Chat wollen wir genau sein, weil sich die Architektur im Projekt geändert hat. Ursprünglich war der Chat Ende-zu-Ende-verschlüsselt gebaut. In der Praxis machte ihn das unbenutzbar: Auf Agenturseite konnte niemand die Nachrichten lesen, solange kein Agenturgerät registriert war, und jeder Gerätewechsel wurde zur Hürde. Am 09.09.2026 wurde die Entscheidung umgekehrt (ADR-0029). Seitdem gilt:

• Übertragung: Text und Bilder gehen per TLS an den Server.

• Speicherung: Der Server verschlüsselt mit AES-256-GCM, bevor er schreibt. In der Datenbank liegt nur Chiffretext.

• Grenze: Wer Server und Schlüssel hat, kann mitlesen. Das ist kein Ende-zu-Ende-Modell, und wir bezeichnen es auch nicht so.

• Altbestand: Nachrichten aus der Zeit davor öffnet die App weiterhin clientseitig mit dem vorhandenen Code (X25519 für den Schlüsselaustausch, AES-256-GCM für Inhalte, private Schlüssel in der Keychain).

Für diesen Altbestand gibt es die Verlaufsfreigabe: Ein Gerät, das alte Nachrichten lesen kann, verpackt deren Inhaltsschlüssel für ein neues Gerät neu – nur für Administratoren. Die Store-Neuerungen sagen es in einem Satz: „Eigentümer-Chat ohne Gerätezwang, auf jedem Gerät lesbar.“ Wir halten das für die redlichere Lösung. Eine Verschlüsselung, die den Betrieb daran hindert, auf Nachrichten zu antworten, schützt am Ende niemanden, sie verschiebt nur die Kommunikation in ungeschützte Kanäle.

Die frühere Angabe „Ende-zu-Ende verschlüsselt“ wird nicht mehr verwendet. Korrekt ist: verschlüsselt gespeichert, per TLS übertragen, E2E-Altbestand wird auf dem Gerät geöffnet.

Eigentümer-Chat auf Agenturseite

Eigentümer haben seit September 2026 eine eigene App. Die Gegenseite des Gesprächs bleibt aber in der Betriebs-App: Threads mit dem Präfix eig: stehen im selben Posteingang wie die Gästenachrichten. Für die Agentur ist das der natürliche Ort, denn eine Eigentümerfrage („Wann wird die Terrasse gemacht?“) hängt oft an denselben Objekten und Aufgaben wie eine Gastfrage.

Der Verlauf kommt über /inbox/{thread}/chat, Bilder lädt die App über signierte URLs aus einem privaten Speicher, gesendet wird über eigentuemerAntworten. Der KI-Vorschlag bekommt im Eigentümer-Chat seit Migration 0708 einen eigenen Kontext aus Objekt, Aufgaben und Belegung – also die Informationen, nach denen Eigentümer typischerweise fragen. Ein kleiner, aber lehrreicher Fehler aus der Einführung: Das Präfix eig: fehlte anfangs in der Präfixliste der App, wodurch vier Werkzeuge im Eigentümer-Chat ins Leere liefen. Seitdem steht die Liste an genau einer Stelle in lib/inbox.ts.

Aufgaben und Reinigungsplanung mit Checklisten und Fotonachweis

Zwischen zwei Buchungen liegt meist ein kurzes Zeitfenster: Abreise um 10 Uhr, Anreise ab 16 Uhr, dazwischen Reinigung, Wäsche, Kontrolle. Die Reinigungsplanung einer Ferienwohnung findet also genau dort statt, wo niemand einen Laptop aufklappt – im Treppenhaus, im Auto, in der Wohnung selbst. Deshalb ist der Aufgabenbereich neben dem Posteingang der zweite Grund, warum eine App für die Ferienwohnungsverwaltung überhaupt mobil sein muss. Gebaut ist er aus HostTasks.tsx, HostTaskCalendar.tsx und TaskDetail.tsx (1.167 Zeilen), gestützt auf reine Logikmodule in lib/, die eigene Tests haben.

Die Aufgabenliste mit den Sichten „Meine“ und „Team“ und den Reitern Aktuell, Bevorstehend und Erledigt. Die Karte „Endreinigung nach Abreise“ zeigt Zeitfenster, Objekt, den Hinweis „Niemand zugewiesen“, das Badge „Überfällig“ und den Knopf „Weiter zu „Angenommen““. Objekt und Aufgabe sind Demo-Daten.

Aufgaben aus Abreisen und Buchungen

Aufgaben entstehen auf drei Wegen, und das Detail zeigt jeweils die Herkunft: „Von Hand angelegt“, „Aus einer planmäßigen Regel“ oder „Aus einer regelmäßigen Regel“. Die Regeln liegen im Backend, nicht in der App – die App ist hier, wie überall, Frontend ohne eigene Fachlogik. Für die Reinigungsplanung heißt das: Eine Endreinigung hängt an der Buchung, trägt deren Referenz und den An- und Abreisetag, und erscheint zur richtigen Zeit in der Liste der zuständigen Person.

Die Liste selbst hat zwei Sichten. „Meine Aufgaben“ zeigt, was dir zugewiesen ist. Verwalter sehen zusätzlich „Team“ mit Filtern nach Objekt und Person. Darunter liegen drei Reiter wie im Web – Aktuell, Bevorstehend, Abgeschlossen –, wobei der Server die Einteilung liefert, damit Web und App nie unterschiedlich zählen. Innerhalb eines Reiters sind die Aufgaben nach Tag gruppiert, mit einer Gruppe „Ohne Termin“ für alles, was keinen Tag hat. Offene Vertretungsanfragen erscheinen als Band über der Liste: Wer krank ist, kann eine Aufgabe zur Übernahme freigeben, und Kolleginnen und Kollegen sehen das sofort.

Ein Punkt, der in der Entwicklung mehr Arbeit gemacht hat als erwartet, ist der Tag einer Aufgabe. Kalendertage von Buchungen rechnet die App in UTC, Aufgaben dagegen nach dem lokalen Tag. Eine Reinigung um 23:30 Uhr muss unter dem richtigen Datum stehen, und eine mehrtägige Wechselaufgabe darf am Anreisetag nicht verschwinden. Die Tageslogik steckt in lib/aufgaben-agenda.ts mit 34 Tests – der am dichtesten getesteten Datei der App. Ein früherer Test war sogar zeitzonenabhängig und schlug nur auf manchen Rechnern fehl.

Statusmodell: von „Offen“ bis „Erledigt“

Der Arbeitszustand einer Aufgabe folgt einer festen Kette, die in lib/aufgabenstatus.ts an genau einer Stelle definiert ist und von Liste, Kalender und Detail gleichermaßen genutzt wird:

1. Offen – die Aufgabe existiert, niemand hat zugesagt.

2. Angenommen – jemand hat zugesagt, aber noch nicht angefangen (seit Migration 0360).

3. In Arbeit – die Person ist vor Ort und arbeitet.

4. Erledigt – abgeschlossen, gegebenenfalls mit QA-Freigabe durch die Leitung.

Daneben gibt es „Abgebrochen“ und – wichtig – einen Rückweg: Aus „Erledigt“ und „Abgebrochen“ führt genau ein Weg zurück nach „Offen“. Den gab es anfangs in der App nicht. Wer versehentlich abgeschlossen hatte, kam nur noch über die Datenbank zurück, obwohl der Server den Wechsel die ganze Zeit erlaubt hätte. Heute ist das Zurücknehmen eine eigene Funktion, getrennt vom „Weiter“, und steht in der Oberfläche auch nicht wie ein Fortschritt da. Ebenfalls eine Lehre aus dem Betrieb: Die Kette stand früher im Listen-Screen und kannte „Angenommen“ nicht, weshalb eine angenommene Aufgabe dort keinen Weiter-Knopf mehr hatte.

Den Arbeitszustand meldet jede zuständige Person selbst. Verteilen, Bewerten und die QA-Freigabe bleiben Verwaltern mit manage_tasks vorbehalten. In der Liste bekommt eine Karte den Knopf „Weiter zu …“ – aber nie für den Schritt nach „Erledigt“. Der Abschluss läuft bewusst über das Detail, weil dort die Foto-Pflicht geprüft wird. Alle schreibenden Wege sind gegen Doppeltipp gesperrt, und schlägt ein Wechsel fehl, zeigt die App den Grund an, statt still nichts zu tun.

Zusätzlich zum Status trägt jede Karte einen Ton, der auf einen Blick sagt, ob Handlungsbedarf besteht:

Die Farben sind absichtlich fest und nicht aus der Markenpalette abgeleitet, weil sie eine Bedeutung tragen, die sich nicht mit einem Farbwechsel im Branding verschieben darf. Die Reihenfolge der Prüfungen ist die des Webs: „heute fällig“ gewinnt über „niemand zugewiesen“, damit die Tagesdringlichkeit nicht hinter einer Zuweisungslücke verschwindet. Unabhängig davon markiert ein Badge „Überfällig“ jede offene Aufgabe, deren Tag schon vorbei ist.

Checklisten je Raum

Eine Reinigungscheckliste für eine Ferienwohnung ist in der Regel nach Räumen gedacht: Küche, Bad, Schlafzimmer, Terrasse. Genau so zeigt das Aufgabendetail die Punkte – gruppiert nach Raum, mit eigenem Fortschritt je Raum und abhakbar. Der Raumkopf erscheint nur dort, wo er etwas unterscheidet: Hat eine Checkliste nur eine namenlose Gruppe, verzichtet die App auf ein wiederholtes „Ohne Raum“. Auf der Karte in der Liste steht zusätzlich ein Fortschrittsbalken, sodass die Leitung schon in der Team-Sicht sieht, wie weit eine Reinigung ist.

Das Detail ist mehr als die Checkliste. Oben stehen Titel, Tag und Zeitfenster, Objekt, Priorität und Herkunft sowie die zuständige Person – für Verwalter antippbar, um neu zu verteilen. Darunter folgt der Buchungsbezug mit Referenz und An- oder Abreisetag, also die eigentliche Arbeitsangabe „ab wann ist das Objekt frei“. Weiter unten liegen Auslagen (etwa für nachgekaufte Reinigungsmittel), eine Rückmeldung „wie ist es gelaufen“ und die Vertretungsanfrage. Vorher bestand das Detail nur aus Titel, Objekt, Zuständigen und Checkliste; eine Aufgabe ohne Checkliste war ein leerer Bildschirm, obwohl das Backend all diese Angaben längst führte.

Eine Regel zieht sich durch alle Aufgabenansichten: Die Reinigungskraft sieht nie einen Gastnamen, eine Adresse des Gasts oder einen Betrag. Die Karte trägt nur die Portal-Referenz, die das Backend eigens dafür mitgibt, und Kalendertage. Auslagen lassen sich nur erfassen, wenn für das Objekt eine Währung hinterlegt ist – ohne Währung erscheint ein Hinweis statt eines Knopfs, damit nie ein erfundenes Euro-Zeichen in einer Abrechnung landet.

Fotonachweis: Kamera nur, wenn sie gebraucht wird

Der Fotonachweis ist in der Reinigungsplanung das, was Diskussionen beendet: Wie sah das Bad aus, als die Reinigung fertig war? Fotos lassen sich pro Checklistenpunkt und zusätzlich an der Aufgabe selbst anhängen, auch wenn es keine Checkliste gibt. Die ganze Bildauswahl liegt in lib/foto.ts, der einzigen Stelle der App, die Kamera oder Bildwähler anspricht. Das ist Absicht: Die Auswahl hat vier Ausgänge – Bild da, abgebrochen, Berechtigung verweigert, technischer Fehler –, und ein Screen, der das nebenbei erledigt, verwechselt gern „abgebrochen“ mit „fehlgeschlagen“ und zeigt eine Fehlermeldung, wo jemand nur zurückgetippt hat.

Die wichtigsten Entscheidungen im Überblick:

• Kamera nur auf Anforderung: Auf Android fragt die App das Kamerarecht erst in dem Moment an, in dem jemand ein Nachweisfoto aufnimmt. Aufgerufen wird das ausschließlich aus dem Aufgabendetail. Im Manifest ist die Kamera als nicht erforderlich deklariert.

• Keine Mediathek-Leseberechtigung auf Android: Für vorhandene Bilder nutzt die App den System-Bildwähler, der einen temporären Zugriff auf genau das gewählte Bild liefert. READ_MEDIA_IMAGES ist nicht deklariert. Unter iOS ist für diesen Weg ein Mediathek-Hinweistext hinterlegt, wie Apple es verlangt.

• Verkleinern vor dem Upload: maximal 1.600 Pixel Kantenlänge bei Qualität 0,8. Ein Handyfoto hat heute schnell 8 bis 12 MB; 1.600 Pixel reichen, um zu zeigen, ob das Bad sauber ist, und sind nur ein Bruchteil der Datenmenge.

• Kein Base64 im Speicher: Die Datei wird über ihren URI als Multipart hochgeladen, statt ein 12-MB-Foto zusätzlich als String im Arbeitsspeicher zu halten.

• Nur JPEG, PNG, WebP: Andere Formate lehnt die App mit einer klaren Meldung ab. Der Server prüft zusätzlich die echten Anfangsbytes der Datei und nicht nur die Endung.

• Kein Zuschnitt, keine Bearbeitung: Ein Nachweisfoto soll zeigen, was da war, nicht was jemand daraus gemacht hat.

Die Foto-Pflicht setzt der Server durch: Verlangt ein Checklistenpunkt ein Foto und fehlt es, lehnt das Backend den Abschluss ab (HTTP 422). Die App zeigt offene Pflichtfotos schon vorher am Punkt an, damit niemand erst beim Abschließen davon erfährt. Hochgeladene Fotos sind über signierte URLs direkt sichtbar. Ein reiner Zähler „2 Fotos“ hätte die Person vor Ort nie sehen lassen, was tatsächlich hochgeladen wurde – und ob das richtige Bild angekommen ist.

Aufgaben-Kalender und Push bei Zuweisung oder Verschiebung

Neben der Liste gibt es einen Aufgaben-Kalender. Das Web zeigt Aufgaben als Zeitleiste mit Objekten als Zeilen und 31 Tagesspalten – auf einem Telefon wäre das eine Fläche zum Wischen ohne Lesbarkeit. Die App nutzt deshalb einen Wochenstreifen von Montag bis Sonntag mit Punktmarkern und darunter die Tages-Agenda des gewählten Tags, mit denselben Karten wie die Liste. Als Strukturvorbild dienten dabei spezialisierte Housekeeping-Apps wie Turno und Breezeway; übernommen haben wir das Muster, nicht deren Code oder Design.

Der Kalender hat zwei Datenwege, je nach Recht. Verwalter laden über /tasks/calendar den Monat mit allen Objekten und ihren Buchungen. Nur damit lässt sich am Tag „Abreise · Anreise“ ausweisen – die Information, wegen der eine Reinigung überhaupt terminiert wird. Mitarbeitende laden nur /tasks/mine. Sie haben keinen Buchungszugriff, also gibt es für sie auch keinen Wechsel-Merker, und die App erfindet ersatzweise keinen.

Für Benachrichtigungen gilt, was oben zum Posteingang steht. Laut Store-Beschreibung bekommen Mitarbeitende einen Push, wenn ihnen eine Aufgabe zugewiesen oder sie verschoben wird. Welche Ereignisse tatsächlich eine Meldung auslösen, entscheidet der Server; die App springt beim Antippen per mynextdays://aufgaben/:id direkt in das Aufgabendetail, auch nach einem Kaltstart. Name des Gasts oder Beträge stehen, wie überall im Push, nicht in der Meldung.

Eine Oberfläche für Reinigungskräfte

Reinigungskräfte, Mitarbeitende und Schichtleitungen bekommen eine deutlich reduzierte App. Ohne das Recht manage_tasks zeigt die Tab-Leiste nur „Aufgaben“ und „Profil“, dazu den Aufgaben-Kalender. Übersicht, Belegungskalender, Buchungen, Posteingang und Inserate werden diesen Rollen nicht nur ausgeblendet, sondern gar nicht erst registriert – und das Backend maskiert zusätzlich. Das ist Datenschutz und Bedienbarkeit zugleich: Wer eine Wohnung reinigt, braucht keine Umsatzzahlen, und jede Schaltfläche weniger ist eine Fehlerquelle weniger.

Für die Bedienung vor Ort haben wir auf ein paar Dinge besonders geachtet:

• Große Ziele: Aktionen wie der Statuswechsel auf der Karte oder „Vertretung anfragen“ im Detail sind als gut treffbare Buttons umgesetzt, teils über die volle Breite. Kleine Symbolknöpfe wie „Auslage zurücknehmen“ bekommen einen erweiterten Tippbereich (hitSlop), damit sie mit dem Daumen treffbar sind.

• Deutsche Klartexte: Die App-Oberfläche ist durchgehend Deutsch; Status heißen „Offen“, „In Arbeit“, „Erledigt“, nicht „open“ oder „done“. Eine Mehrsprachigkeit der Oberfläche gibt es derzeit nicht.

• Schlechtes Netz: Einen Offline-Modus hat die App nicht, und wir behaupten auch keinen. Sie geht aber ehrlich mit Funklöchern um: Schlägt das Laden fehl, steht „Aufgaben nicht geladen.“ mit dem Grund da, statt eines beruhigenden „Dir ist keine Aufgabe zugewiesen“, das über einen Ladefehler falsch wäre. Neu geladen wird per Pull-to-Refresh; andere Screens bieten einen Knopf „Erneut versuchen“.

• Kleine Uploads: Die Verkleinerung der Fotos ist ausdrücklich für den Keller ohne Empfang gedacht, wo ein 12-MB-Upload scheitern würde.

• Ruhige Leerzustände: „Nichts offen – Dir ist gerade keine Aufgabe zugewiesen“ oder „Nichts geplant“ sagen klar, dass alles in Ordnung ist.

Diese Art Reinigungsplanung per App lässt sich für viele Betriebe übertragen. Wenn du Abläufe dieser Art für dein eigenes Unternehmen digitalisieren willst, findest du unseren Ansatz auf der Seite zur App-Entwicklung mit React Native und Flutter.

Eigentümer: eine eigene App statt eines versteckten Tabs

Bis zum 09.09.2026 enthielt die Betriebs-App ein komplettes Eigentümer-Erlebnis mit sieben Screens für Objekte, Kalender, Einnahmen, Statistik, Anfragen, Objektdetail und Fotoalbum. Seitdem liegt es ausschließlich in der separaten App „myNextDays Eigentümer“ (com.mynextdays.owner). Sie trägt dieselbe Marke und Farbe, ist also kein Seitenprojekt, sondern eine zweite Tür in dasselbe System – mit eigenen Screens für Überblick, Auszahlungen, Abrechnungen, Chat, Sperranträge, Zählerstände und Fotoalbum.

Warum getrennt? Eine App, die je nach Rolle zwei völlig verschiedene Produkte zeigt, ist schwer zu erklären, schwer zu testen und im Store schwer zu beschreiben. Eigentümer haben andere Fragen als eine Agentur: Wann ist mein Haus belegt, was wurde ausgezahlt, wann darf ich selbst hinein? Diese Fragen verdienen eine eigene, schlanke Navigation statt eines Tabs, der in einer Verwaltungs-App zwischen Buchungen und Aufgaben steckt. Hinzu kommt die Rechtetrennung: Jede App registriert nur die Screens ihrer Zielgruppe, und Push-Meldungen werden je Kategorie an die richtige App geroutet.

Was die Haupt-App für Eigentümer noch zeigt, ist die Sicht der Agentur auf Eigentümer: Eigentümer-Aufenthalte im Kalender, die Kachel „Eigentümer-Vorgänge“ auf der Übersicht und den Eigentümer-Chat im Posteingang. Meldet sich jemand mit der Rolle owner in der Betriebs-App an, landet er nicht in einem leeren Dashboard und schon gar nicht ersatzweise in der Agenturansicht, sondern auf dem Screen OwnerAppHinweis. Er erklärt die Lage und bietet den Wechsel an. Die Eigentümer-App hat das Gegenstück: Dort fängt FalscheRolle.tsx ein Verwaltungskonto ab.

Den Absprung erledigt lib/appwechsel.ts, eine CI-geprüfte Schwesterdatei, die in allen Apps identisch ist. Sie prüft mit canOpenURL, ob die Zielapp installiert ist, und öffnet sie über ihr Scheme (mynextdaysowner://). Fehlt sie, geht es in den Store – nie ein stiller No-Op, bei dem der Nutzer tippt und nichts passiert. Damit das funktioniert, deklariert das Android-Manifest die Schemes der Schwester-Apps unter <queries>, und nur diese.

Für die Store-Prüfung hat die Trennung einen praktischen Vorteil. Jede App beschreibt genau eine Zielgruppe, ihre Screenshots zeigen genau deren Oberfläche, und Prüfer müssen nicht mehrere Rollen durchspielen, um alle Funktionen zu sehen. Ein Wermutstropfen gehört zur Ehrlichkeit: Die Play-Store-Beschreibung der Betriebs-App enthält noch einen veralteten Abschnitt „Für Eigentümer“; die Release-Notes sagen dagegen korrekt: „Das Eigentümer-Portal ist ausgezogen – es hat eine eigene App.“

Design und UX: ein Verwaltungssystem auf sechs Zoll

Ein PMS mit Channel Manager ist im Web ein Werkzeug mit Dutzenden Seiten, Tabellen und Einstellungen. Die Frage war nie, wie wir das alles auf ein Telefon quetschen, sondern was auf dem Telefon überhaupt gebraucht wird – und in welcher Reihenfolge. Die Antwort bestimmt, ob eine Ferienwohnung Verwaltung App im Alltag benutzt wird oder nach einer Woche wieder vom Homescreen verschwindet. Unsere Arbeit im Bereich UI/UX-Design setzt deshalb bei der Struktur an, nicht bei den Farben.

Informationsarchitektur: fünf Tabs

Für Verwalter hat die App genau fünf sichtbare Tabs: Übersicht, Kalender, Buchungen, Posteingang, Mehr. Die Reihenfolge folgt dem Tag: morgens die Übersicht mit Anreisen, Abreisen und Kennzahlen, dann der Belegungskalender, die Buchungen und der Posteingang als ständiger Begleiter. Alles, was seltener gebraucht wird – Aufgaben, Aufgaben-Kalender, Inserate, Bewertungen und Profil –, liegt hinter „Mehr“. Diese Screens sind im Navigator registriert, bekommen aber keinen eigenen Tab-Button, damit die Leiste bei fünf Einträgen bleibt. Mehr als fünf Tabs werden auf schmalen Displays schnell unleserlich.

Für Mitarbeitende und Reinigung schrumpft die Leiste auf „Aufgaben“ und „Profil“. Welcher Satz erscheint, hängt nicht am Rollennamen, sondern an der Capability manage_tasks aus /auth/me – so können Betriebe eigene Rollen zuschneiden, ohne dass die App neu gebaut werden muss. Tiefer liegende Inhalte sind per Deep-Link erreichbar, etwa mynextdays://reservierungen/:id oder mynextdays://inbox/:threadId, was Push-Meldungen und Verknüpfungen zwischen Screens einfach macht. Buchungsdetails öffnen sich in allen Einstiegen als Panel, das von rechts einfährt und sich per Wisch, Knopf, Tipp auf die Abdunkelung oder die Android-Zurück-Taste schließt.

Designsystem: Farben, Typografie, Chips und Kanal-Logos

Das Designsystem ist klein gehalten und in theme/tokens.ts sowie einem eigenen UI-Kit abgelegt. Der Markenakzent ist #C42B3A, bewusst zwischen den beiden Logo-Rottönen gewählt. Die helle Palette nutzt seit dem 15.09.2026 einen warmen Hintergrund (#F5F3F0) statt reinem Weiß – vorher waren Hintergrund und Karten identisch weiß, und die Rückmeldung lautete sinngemäß: „Unsere App ist nur weiß.“ Eine dunkle Palette folgt der Systemeinstellung und lässt sich überschreiben.

Bei den Kanälen gilt eine klare Regel, die in components/KanalMarke.tsx umgesetzt ist: nur echte Portal-Logos. Für Booking.com, Airbnb und Vrbo zeigt die App die Wortmarke als Pille, die dem Logo seine Breite lässt – in einen kleinen Kreis gequetscht wäre es nur ein Fleck. Kanäle ohne offizielles Logo, etwa Direktbuchungen oder die eigene Website, bekommen einen Punkt in ihrer Kanalfarbe statt eines gebastelten Buchstabens. Im Posteingang, wo der Platz am Avatar knapp ist, trägt ein kleines Rund den Anfangsbuchstaben in derselben Kanalfarbe. Die Logos sind Herkunftsanzeige, keine Behauptung einer Partnerschaft mit den Portalen. Rohe Kanalcodes erscheinen als Klarname, also „Booking.com“ statt „BookingCom“.

Als Strukturvorbilder nennt der Code das Muster der Airbnb-App (feine Linien, flache Radien) und für Fachfunktionen Hostaway, Lodgify, Breezeway und Turno. Das sind Referenzen für Aufbau und Bedienlogik, keine Kooperationen – und genau so arbeiten wir: bewährte Muster aus dem Markt verstehen und dann für den konkreten Betrieb neu umsetzen.

Leerzustände, Fehlergrenze und Demo-Band

Ein großer Teil guter UX in einer Verwaltungs-App liegt in den Zuständen, die im Mockup nie vorkommen: leer, fehlerhaft, gesperrt. Die App trennt Laden, Fehler und Leere konsequent. Ein Ladefehler wird nie als „keine Daten“ ausgegeben, und es gibt keinen Demo-Fallback, der bei Netzproblemen Beispielzahlen einblendet. Leerzustände nutzen ein gemeinsames Muster aus Icon, Titel und einem Satz Kontext – „Noch nichts abgeschlossen“ erklärt zum Beispiel, dass erledigte Aufgaben hier erscheinen, sobald die erste fertig ist.

Ganz außen um die App liegt eine Fehlergrenze (React Error Boundary). Ohne sie wäre jeder unbehandelte Fehler im Release ein harter Absturz. Mit ihr sieht der Nutzer eine ruhige Meldung und einen Knopf „Erneut versuchen“ – ohne Stacktrace und ohne interne Pfade, die für den Betrieb wertlos wären und eher nach kaputtem Produkt aussehen. Die technische Diagnose geht anonym, ohne Token, an einen eigenen Endpunkt des Backends. Ein Crash-SDK eines Drittanbieters gibt es bewusst nicht.

Für Vorführungen gibt es das Demo-Band. Der Vorführ-Zugang darf nichts speichern; das Backend lehnt schreibende Anfragen ab. Ohne Hinweis erlebten Testpersonen das als Defekt: Antwort tippen, senden, nichts passiert. Seit dem 19.08.2026 zeigt die App bei Demo-Konten im Posteingang und im Profil dauerhaft den Satz „Vorführung — ansehen ja, speichern nein.“ – nicht wegklickbar, weil ein geschlossener Hinweis genau in der Sitzung fehlen würde, in der er gebraucht wird. Alle Screenshots dieser Case Study stammen aus diesem Vorführ-Mandanten.

Bedienung mit einer Hand und Barrierefreiheit

Eine Verwaltungs-App wird oft mit einer Hand bedient, während die andere einen Schlüssel, eine Tasche oder einen Wäschesack hält. Unser Ansatz dafür ist strukturell: Die Hauptnavigation liegt unten in der Daumenzone, die häufigsten Aktionen stehen als breite Buttons in der Karte, und Bottom Sheets statt verschachtelter Dialoge halten Filter, Vorgangsaktionen und Formulare im unteren Bildschirmbereich. Das ist ein Gestaltungsprinzip, keine gemessene Kennzahl – eine formale Einhand-Studie haben wir nicht durchgeführt.

Zur Barrierefreiheit ist im Code Folgendes belegt:

• 156 Vorkommen von accessibilityLabel und accessibilityRole in 32 Dateien, etwa „Zuständige Person ändern“ am Zuweisungsknopf.

• Die Tab-Leiste skaliert mit der Systemschrift und rechnet Schriftgröße und Safe Area in ihre Höhe ein; die Skalierung ist bewusst nicht abgeschaltet. Anlass war eine Leiste, deren Beschriftung bei großer Schrift abgeschnitten wurde.

• Der aktive Tab ist nicht nur farbig, sondern hat zusätzlich eine stärkere Strichstärke – Zustand also nicht allein über Farbe.

• Kontraste wurden nach der WCAG-Formel gemessen und angepasst, unter anderem mit einem eigenen Token für Akzenttext und einer Funktion, die die Schriftfarbe auf farbigen Flächen nach Luminanz wählt.

• Das Demo-Band ist als dauerhafte Randbedingung ausgezeichnet und nicht als Alarm, damit der Screenreader nicht bei jedem Seitenwechsel unterbricht.

Eine WCAG-Konformität oder einen vollständigen Accessibility-Audit behaupten wir damit nicht. Was die App leistet, ist eine solide Grundlage, auf der sich ein Audit aufsetzen ließe. Für uns gehört das zur ehrlichen Einordnung eines Projekts: Die App zur Ferienwohnungsverwaltung ist an vielen Stellen bewusst zugänglich gebaut, aber noch nicht formal geprüft.

Architektur: React Native 0.86, React 19, Supabase und FastAPI

Von außen sieht man einer Business-App ihre Architektur nicht an. Man merkt sie trotzdem jeden Tag: am Kaltstart am Morgen, an einer Push-Nachricht, die ankommt oder eben nicht, an einem Kalender, der beim ersten Wischen flüssig bleibt. Bei myNextDays haben wir die Architektur von Anfang an so gebaut, dass die App keine eigene Fachlogik enthält. Sie spricht dieselbe FastAPI-Schnittstelle /api/v1 an wie das Web-Dashboard und arbeitet auf demselben Datenbestand. Der Kopfkommentar in lib/api.ts sagt es knapp: „Business-Logik bleibt im Backend; die App ruft nur HTTP.“ Alles, was jetzt folgt, baut auf dieser einen Entscheidung auf.

Für dich als Entscheider heißt das: Eine Preisregel, eine Berechtigung oder eine Stornologik gibt es genau einmal, nämlich auf dem Server. Web und App können sich deshalb nicht widersprechen. Für Entwickler heißt es: Die App ist ein schlanker, aber anspruchsvoller Client mit sauberer Auth, Realtime, Push und einem eigenen Weg für Fehlerberichte. Wie wir allgemein an React Native App-Entwicklung herangehen, steht in unserem Guide. Hier geht es um das konkrete Projekt.

Warum bare React Native statt Expo – und warum nicht Flutter

Die App läuft auf bare React Native, also mit der React-Native-CLI und ohne Expo. Das steht so schon im allerersten App-Commit vom 18.06.2026 („bare React Native, kein Expo“) und im README. Eine ausführliche Abwägung dazu gibt es in den ADRs nicht. Die Gründe lassen sich aber gut am Code ablesen. Die App braucht mehrere native Bausteine, die wir selbst im Griff haben wollten: react-native-keychain für Tokens im iOS-Keychain und im Android Keystore, react-native-quick-crypto für den Kryptografie-Altbestand im Eigentümer-Chat, Firebase Messaging über CocoaPods und einen Push-Kanal, den wir nativ in Kotlin anlegen.

Dazu kommt der Build selbst. Signierung, Versionsnummern und das Verhalten ohne Release-Schlüssel steuern wir direkt in Gradle. Fehlt der Schlüssel, entsteht bewusst ein unsigniertes Paket statt eines Pakets, das still mit dem Debug-Key signiert wurde. Mit Expo und EAS lässt sich vieles davon ebenfalls erreichen, über Config-Plugins und Development-Builds. Das ist ein legitimer Weg, und für viele Apps ist er der schnellere. Hier wollten wir aber die android/- und ios/-Projekte als normalen, lesbaren Quellcode im Repository haben. Kein generierter Zwischenschritt sollte zwischen uns und einem Fehler im Release-Build stehen. Wie oft das zählt, zeigt der Abschnitt zu den Herausforderungen weiter unten.

Und Flutter? Flutter ist ein starkes Framework, das haben wir in unserem Flutter-Vergleich ausführlich beschrieben. Den Ausschlag gab hier das Umfeld. Das Web-Dashboard von myNextDays ist eine Next.js-Anwendung mit React und TypeScript. Mehrere App-Module sind direkte Portierungen von Web-Modulen. lib/use-buchungsdetail.ts stammt aus web/lib/use-reservation-detail.ts, und lib/inbox-access.ts spiegelt die Zugriffsregeln des Web-Posteingangs Zeile für Zeile. Die deutschen Ausstattungs-Labels werden per Skript aus den Web-Übersetzungen erzeugt. Mit Dart hätten wir diese Logik jedes Mal neu schreiben und getrennt pflegen müssen. Mit TypeScript bleibt es eine Sprache, ein Denkmodell und oft sogar dieselbe Funktion.

Unsere Faustregel: Das Framework folgt dem Team und dem bestehenden Code, nicht dem Hype. Wenn Web und Backend-Schnittstellen schon in TypeScript und React leben, ist React Native fast immer die günstigere Wahl über die Lebensdauer der App.

Tech-Stack im Überblick

Die folgenden Versionen stammen direkt aus der package.json und den Gradle-Dateien der App, Stand September 2026. Wir führen sie so genau auf, weil gerade bei React Native die Kombination der Versionen entscheidet, ob ein Update ein Nachmittag oder eine Woche wird.

Auffällig ist eher, was fehlt. Es gibt keine Chart-Bibliothek: Die Verlaufskurve auf der Übersicht zeichnen wir selbst mit react-native-svg. Es gibt kein Redux und keinen anderen globalen Store. Zustand liegt in React-Hooks und einem einzigen Context für die Anmeldung. Und es gibt kein Analytics-, Werbe- oder Crash-SDK. Nativer Eigencode in Swift und Kotlin umfasst zusammen nur 168 Zeilen. Der Rest ist TypeScript. Mehr zur New Architecture von React Native und zu React 19 findest du in der offiziellen Dokumentation.

App-Aufbau: Navigation, Screens, lib-Module, TypeScript

Der Einstieg ist index.js. Dort setzen wir als Allererstes den globalen Absturz-Handler und registrieren danach den Push-Hintergrund-Handler, in einem try/catch und per require. Scheitert Firebase, startet die App trotzdem. App.tsx baut dann eine klare Kette von Hüllen auf: Fehlergrenze, Gesture-Handler, Safe Area, Theme, Auth-Provider und schließlich die Navigation mit einem Native Stack und der Tab-Leiste. Geschützte Screens existieren im Navigator nur, wenn eine Sitzung besteht. Ein Deep-Link auf eine geschützte Route läuft im ausgeloggten Zustand deshalb ins Leere, statt einen halb geladenen Screen zu zeigen.

Der Umfang in Zahlen, gemessen ohne node_modules und native Ordner:

• 128 TypeScript-Dateien mit 30.165 Zeilen, davon rund 27.600 Zeilen App-Code und 2.527 Zeilen Tests

• 21 Screens mit zusammen 10.220 Zeilen, der größte ist der Posteingang mit 1.429 Zeilen

• 46 Dateien in lib/ mit 8.185 Zeilen: API-Client, Auth, Berechtigungen, Kalenderlogik, Posteingang, Aufgaben, Währung, Realtime, Push

• 31 Komponenten in Ordnern nach Fachbereich (aufgaben, buchung, dashboard, inbox, objekte, ui)

• 3 Navigations-Dateien, 1 Context, 3 Theme-Dateien, 64 eigene SVG-Icons

Die Trennung ist streng. Screens rendern, lib/ rechnet und spricht mit dem Server. Reine Logik wie die Sortierung der Buchungen, die Statuskette der Aufgaben oder die Umwandlung der Gästemappe von HTML in Text liegt in kleinen, testbaren Modulen. TypeScript nutzt das offizielle React-Native-Profil (@react-native/typescript-config), geprüft wird per tsc --noEmit. Eine Besonderheit sind die Schwesterdateien. Die Plattform hat drei Apps, und Dateien wie realtime.ts, currency.ts, rechtliches.ts oder die Fehlergrenze tragen einen SCHWESTERDATEI-Kopf. Ein CI-Job prüft, dass sie in allen Apps byte-identisch bleiben. Das ist bewusst eine Kopie mit Prüfung und kein gemeinsames Paket, weil jede App ihr eigenes Lockfile und ihren eigenen Release-Takt behält.

Auth: Supabase-JWT, FastAPI /api/v1, Keychain und Keystore, 2FA

Die Anmeldung läuft über POST /api/v1/auth/login, also über dieselbe Schnittstelle wie im Web. Die JWTs stellt Supabase GoTrue aus, das laut Architekturentscheidung als eigenständiger Identity-Provider arbeitet. Die FastAPI prüft sie und liest daraus Mandant und Rolle. Die Antwort des Logins ist eine Hülle mit den Feldern mfa_required und session. Genau das hat uns einmal einen Fehler beschert, dazu unten mehr.

Access-Token, Refresh-Token und Ablaufzeit liegen in getrennten Einträgen im iOS-Keychain bzw. im Android Keystore, über react-native-keychain. Sie liegen nicht in AsyncStorage und nicht in einer Datei. Ein Kommentar in lib/auth.ts hält fest: Tokens werden nie geloggt. Beim Kaltstart prüft die App die gespeicherte Ablaufzeit mit 30 Sekunden Toleranz und frischt das Token vorsorglich auf, bevor der erste Screen Daten lädt.

Die Zwei-Faktor-Anmeldung ist zweistufig aufgebaut:

1. Ist ein Faktor aktiv, liefert der Login eine vorläufige Sitzung (aal1) und die verfügbaren Methoden. Diese Sitzung bleibt nur im Arbeitsspeicher und landet nie im Keychain.

2. Die App löst den zweiten Faktor direkt gegen GoTrue (TOTP oder SMS) und erhält eine vollwertige Sitzung (aal2). Erst die wird gespeichert.

3. Eingerichtet wird TOTP im Profil ohne QR-Code: Auf dem Telefon, das den Code ja selbst erzeugt, gibt es einen antippbaren otpauth-Link und das Secret zum Abtippen.

Die frühere 2FA-Variante über einen eigenen Endpunkt ließ sich über den GoTrue-Direktlogin umgehen. Deshalb wurde sie serverseitig ersetzt. 2FA ist freiwillig, eine Pflicht je Rolle gab es kurz und wurde am 25.08.2026 wieder entfernt. Recovery-Codes funktionieren beim mobilen Login bewusst nicht. Wer sein Gerät verliert, braucht einen Admin-Reset.

Ein Detail, das Nutzer nie sehen, aber sofort spüren würden: der Token-Refresh ohne Logout bei Netzfehler. Laufen mehrere Anfragen gleichzeitig in einen 401, teilen sie sich ein einziges Refresh-Promise (single-flight). Der Grund ist das Rate-Limit der Auth mit 10 Anfragen pro 60 Sekunden und IP. Der API-Client versucht genau einmal einen Refresh und eine Wiederholung, eine Retry-Schleife gibt es nicht. Scheitert der Refresh an einem Netzfehler, etwa im Keller eines Ferienhauses ohne Empfang, bleiben die Tokens erhalten. Die App zeigt einen Fehlerzustand mit „Wiederholen“ und meldet den Nutzer nicht ab. Einen Offline-Modus mit lokaler Datenhaltung gibt es nicht, das haben wir bewusst so entschieden.

• /auth/login → Hülle mit mfa_required und session

• /auth/refresh → neues Token-Paar, single-flight

• /auth/me → Rolle, Capabilities, Permissions, Mandant, Demo-Kennzeichen

• /auth/account/deletion → Löschung oder Löschantrag (GET/POST/DELETE)

Wenn du eine ähnliche Anbindung planst, ist die saubere Schnittstelle der wichtigste Teil. Genau das machen wir in der Backend- und API-Entwicklung.

Realtime und Push

Kalender, Buchungsdetail und Marktplatz-Bewertungen aktualisieren sich live über Supabase Realtime, also per WebSocket auf postgres_changes und ohne Polling. Der Realtime-Client ist ein Singleton ohne eigene Sitzung (persistSession:false). Das App-JWT wird vor dem subscribe() gesetzt, damit Row Level Security schon beim Beitritt zum Kanal greift und nur Änderungen des eigenen Mandanten ankommen. Mehr zu diesem Prinzip steht in der Supabase-Dokumentation zu Row Level Security. Es gibt genau eine Tokenquelle pro App. Fehlt sie, verweigert der Hook den Dienst, statt anonym zu verbinden.

Es gibt zwei Modi: onChange lädt nach einer Änderung mit 400 ms Entprellung neu, onEvent arbeitet inkrementell. Der Posteingang nutzt bewusst kein Realtime. Die Tabellen dahinter sind serverseitig für direkte Clientzugriffe gesperrt. Dort aktualisieren wir beim Öffnen, beim Senden und per Pull-to-Refresh. Das ist eine Sicherheitsentscheidung, keine Nachlässigkeit, und wir dokumentieren sie im Code genau so.

Für Push nutzen wir Firebase Cloud Messaging, und zwar nur die Pakete app und messaging. Der Ablauf:

• Android 13 und neuer fragt die Benachrichtigungsberechtigung zur Laufzeit ab. Ohne sie verwirft das System Meldungen still.

• Das Gerätetoken wird per PUT /notification-settings/push-geraet gemeldet, mit der App-Kennung mynextdays, damit der Server es von der Eigentümer-App unterscheidet. Erneuerte Tokens werden nachgemeldet.

• Der Benachrichtigungskanal wird nativ angelegt, der Headless-Task hat 30 Sekunden Zeit.

• Im Hintergrund zeigt das Betriebssystem die Meldung selbst an. Im Vordergrund zeigt die App keine Meldung, weil dort ohnehin Realtime läuft.

• Ein Tipp auf die Meldung wird auf einen Deep-Link abgebildet, etwa zu einer Buchung, einer Aufgabe oder einem Gesprächsverlauf. Das funktioniert auch aus dem geschlossenen Zustand.

• Beim Logout meldet die App das Gerät ab, bevor das Token gelöscht wird. Sonst bekäme ein abgemeldetes Telefon weiter Nachrichten über Gäste.

Welche Ereignisse eine Push-Nachricht auslösen, entscheidet der Server. Die App empfängt generisch und leitet weiter. So lässt sich die Logik ändern, ohne dass ein neues App-Release nötig ist.

Crash-Reporting ohne Tracking-SDK

Crashlytics und Sentry sind die üblichen Antworten auf die Frage, wie man Abstürze mitbekommt. Wir haben keines von beiden eingebaut. Die interne Dokumentation begründet das nüchtern: Crashlytics fängt in React Native zwar auch JavaScript-Fehler, kann sie in der Konsole aber nicht über Source-Maps auflösen. Man braucht also ohnehin einen eigenen Weg. Ein weiteres SDK hätte außerdem jede Angabe im Formular zur Datensicherheit verändert. Stattdessen hat die App einen eigenen, anonymen Absturzweg:

• Fehlergrenze: Eine React Error Boundary ganz außen fängt Renderfehler. Im Release sieht der Nutzer eine ruhige Meldung mit „Erneut versuchen“ und keinen Stacktrace.

• Globaler Handler: Ein ErrorUtils-Handler meldet unbehandelte Fehler an POST /api/v1/diagnostics/startabsturz, ohne Token und damit ohne Bezug zu einem Konto.

• Inhalt: Meldung, Stacktrace (höchstens 4.000 Zeichen), Komponentenkette, Plattform und OS-Version sowie die Millisekunden seit Prozessstart

• Grenzen: höchstens fünf Meldungen pro Sitzung, ein nacktes fetch ohne await, damit die Meldung selbst nie einen zweiten Absturz auslöst

• Probe: Über den Deep-Link mynextdays://absturz-probe lässt sich der Weg ohne sichtbaren Knopf testen.

Entstanden ist das aus einem echten Problem. Beta-Tester meldeten Abstürze, konnten aber verständlicherweise kein Geräteprotokoll liefern. Heute kommt die Information an, ohne dass ein Drittanbieter Gerätedaten bekommt. In der Datensicherheit taucht sie korrekt als Absturzdaten auf, die nicht mit der Identität verknüpft sind.

Hosting in Europa (Hetzner) und Architekturprinzipien

Das Backend ist eine FastAPI-Anwendung in Python mit Vertical-Slice-Architektur. Fachbereiche wie Posteingang, Aufgaben oder Kontolöschung sind jeweils als eigener Slice organisiert. Supabase mit Postgres, GoTrue, Storage und Realtime läuft self-hosted, mandantenfähig mit Row Level Security. Der Mandant steckt im JWT. Betrieben wird das Ganze mit Coolify auf Hetzner in der EU, die API ist unter api.mynextdays.com erreichbar. Wie wir Datenmodelle und RLS-Regeln für solche Systeme aufbauen, beschreiben wir unter Datenbank-Entwicklung mit Postgres. Die Grundlage für FastAPI ist die offizielle FastAPI-Dokumentation.

Im Code wird immer wieder auf eine Handvoll Prinzipien verwiesen, die im Projekt „Wurzeln“ heißen. Wir finden sie nützlich über dieses Projekt hinaus. Deshalb stehen die wichtigsten hier in Kurzform:

Datenschutz, DSGVO und Google-Play-Compliance

Eine App, mit der Betriebe Gästedaten, Buchungen und Beträge verwalten, braucht Datenschutz von Anfang an. Nachträglich einbauen lässt er sich schlecht. Bei myNextDays haben wir die DSGVO-konforme App nicht über ein Consent-Banner gelöst, sondern über Weglassen: keine Daten erheben, die für die Funktion nicht nötig sind, keine Dritten einbinden, die mitlesen. Der Verordnungstext steht im DSGVO-Volltext bei EUR-Lex. Die Store-Regeln von Google und Apple verlangen im Kern dasselbe, nur formularförmig.

Privacy by Design: kein Tracking, keine Werbe- oder Analyse-SDKs

Die Abhängigkeitsliste der App enthält kein Analytics-, kein Werbe- und kein Crash-SDK. Von Firebase sind nur der Kern und Messaging eingebunden. Im iOS Privacy Manifest steht NSPrivacyTracking = false, jede deklarierte Datenart trägt Tracking = false. Einen App-Tracking-Transparency-Dialog gibt es deshalb nicht, er wäre schlicht gegenstandslos. Eine App ohne Tracking ist dabei kein Marketingargument, sondern eine technische Eigenschaft, die man im Build prüfen kann.

Dazu kommen einige Entscheidungen, die man erst auf den zweiten Blick sieht:

• android:allowBackup="false": App-Daten landen nicht in automatischen Cloud-Backups.

• Tokens liegen nur im Keychain bzw. Keystore und werden nie geloggt.

• Die Objektkartei lädt die Stufe mit den Bankdaten und Steuernummern der Eigentümer bewusst nicht auf das Telefon.

• Reinigungskräfte sehen an einer Aufgabe nur Buchungsreferenz und Tage, nie Gastnamen oder Beträge. Das Backend maskiert, die App zeigt nur an.

• Die App fragt keinen Standort und keine Kontakte ab. Die Umkreissuche gehört zum Marktplatz, nicht zur Betriebs-App.

Das Formular zur Datensicherheit ehrlich ausfüllen

Das Formular zur Datensicherheit in der Play Console wird oft aus dem Gedächtnis ausgefüllt. Wir haben es gegen das gebaute Binary abgeglichen. Dabei fiel am 31.08.2026 auf, dass drei Datenarten fehlten, die die App tatsächlich verarbeitet: Fotos aus dem Fotonachweis, Geräte-IDs in Form des Push-Tokens und die anonymen Absturzdaten. Wir haben sie nachgetragen. Seitdem stimmt die Google Play Datensicherheit mit dem überein, was der Code tut.

Der Play-Store-Eintrag fasst das in drei Sätzen zusammen: Es werden keine Daten mit Drittunternehmen geteilt, Daten werden bei der Übertragung verschlüsselt, und du kannst die Löschung beantragen. Mehr steht dort bewusst nicht, auch keine pauschale Aussage über die Verschlüsselung von Chats. Die Gesprächsinhalte im Eigentümer-Chat werden verschlüsselt gespeichert und per TLS übertragen. Mehr versprechen wir nicht, weil mehr nicht stimmen würde.

Minimale Berechtigungen

Das Android-Manifest fordert genau drei Berechtigungen an: INTERNET, POST_NOTIFICATIONS und CAMERA. Die beiden letzten werden zur Laufzeit abgefragt, und zwar erst dann, wenn sie gebraucht werden. Die Kamera fragt die App nur in einer einzigen Funktion an, und die wird nur aus dem Aufgaben-Detail für den Fotonachweis aufgerufen. Das haben wir per Codesuche verifiziert. Die Kamera ist außerdem als optional deklariert, die App lässt sich also auch auf Geräten ohne Kamera installieren.

Auf Android gibt es keine Leseberechtigung für die Mediathek, also kein READ_MEDIA_IMAGES. Wer ein vorhandenes Foto auswählen will, nutzt den System-Photo-Picker, und die App bekommt nur einen temporären Verweis auf genau dieses eine Bild. Google empfiehlt diesen Weg ausdrücklich, siehe Android: Datenschutz und Berechtigungen. Im <queries>-Block stehen nur die beiden Schwester-Apps, damit die App prüfen kann, ob sie installiert sind.

Unter iOS sind zwei Nutzungstexte deklariert: NSCameraUsageDescription („Damit du Nachweisfotos zu Aufgaben aufnehmen kannst.“) und NSPhotoLibraryUsageDescription für die Auswahl vorhandener Fotos als Nachweis. Das ist Pflicht, sobald der Bildwähler dort angeboten wird. Wir erwähnen es, weil man sonst leicht den falschen Schluss zieht, die App komme auf beiden Plattformen ohne jede Mediathek-Deklaration aus.

Konto-Löschung in der App und per Web-Link

Google und Apple verlangen, dass ein Konto sich dort löschen lässt, wo es genutzt wird, also in der App, und zusätzlich über einen Weg außerhalb der App. Die Anforderungen von Google Play zur Kontolöschung und der Beitrag im Android Developers Blog zum Design der Löschung beschreiben das ausführlich. Bei myNextDays sieht die Umsetzung so aus:

1. Im Profil erklärt ein erster Schritt, was passiert und was aufbewahrt werden muss.

2. Das aktuelle Passwort ist Pflicht. Ein Grund kann freiwillig angegeben werden.

3. Mitarbeiter, Eigentümer und Co-Admins werden sofort gelöscht und abgemeldet.

4. Beim Kontoinhaber entsteht ein Löschantrag, der sichtbar ist und sich zurückziehen lässt. Mit dem Inhaberkonto hängt ein ganzer Betrieb mit Buchungen und Rechnungen zusammen, deshalb wird hier nicht per Knopfdruck alles entfernt.

5. Außerhalb der App gibt es den Web-Weg unter mynextdays.com/konto-loeschen.

„Rechnungen, Zahlungen und Buchungsbelege bleiben aus gesetzlicher Aufbewahrungspflicht erhalten (Buchführung, 5 Jahre) und werden vom Konto getrennt.“ – Hinweistext in der App

Dieser Satz ist wichtiger, als er klingt. Viele Löschdialoge versprechen „alle Daten“ und können das rechtlich gar nicht halten. Wir sagen vorher offen, was bleibt und warum.

Keine Käufe in der App

Die App verkauft nichts. Es gibt keine In-App-Käufe, keine Abo-Verwaltung und keinen Link zu einer Kaufseite. Das Abonnement eines Betriebs läuft außerhalb der App, der Store-Eintrag sagt entsprechend „Kostenlos“. Auch die Registrierung eines neuen Betriebs haben wir am 19.08.2026 aus der App entfernt, der Link „Noch kein Konto?“ öffnet heute den Browser. Für die spätere Prüfung im App Store argumentieren die vorbereiteten Review-Notes mit der Einordnung als Unternehmensanwendung (Apple 3.1.3(c)). Für Zusatzleistungen wie eine Endreinigung, die im Buchungsdetail als bezahlt markiert werden, gilt 3.1.3(e): Das sind reale Leistungen zwischen Betrieb und Gast, keine digitalen Güter.

Rollen nach DSGVO und Rechtstexte in der App

Bei einem PMS muss man sauber trennen, wer für welche Daten verantwortlich ist. Für die Gastdaten ist der Betrieb der Verantwortliche, also die Agentur oder der Vermieter, der die App nutzt. myNextDays ApS ist Auftragsverarbeiter und stellt dafür einen Auftragsverarbeitungsvertrag bereit. Zu den Unterauftragsverarbeitern gehören unter anderem Hetzner als Hoster, Zahlungsdienstleister und E-Mail-Dienste. Die Liste liegt beim Anbieter.

In der App verlinkt ein eigener Block fünf Dokumente, die im Browser öffnen: Datenschutzerklärung, Nutzungsbedingungen, Auftragsverarbeitung, Cookie-Richtlinie und Impressum. Die Anbieter-Pflichtangaben stehen zusätzlich als Text in der App, also Firma, Adresse und Land. Damit sind sie auch ohne Netz lesbar. Das ist die einzige Stelle der App, die offline funktioniert. Die Begründung im Code verweist auf Apples Regel 5.1.1(i) und das dänische E-Handelsgesetz. Die Datei mit diesen Angaben ist eine Schwesterdatei und wird von der CI über die Apps hinweg identisch gehalten.

Qualität, Tests und Launch im Google Play Store

Zwischen „läuft auf meinem Telefon“ und „liegt im Store und läuft bei Kunden“ liegt der Teil der App-Entwicklung, den kaum jemand plant und der trotzdem die meisten Nerven kostet. Hier beschreiben wir, wie wir testen, bauen, signieren und veröffentlichen, und was dabei tatsächlich schiefgegangen ist.

Teststrategie

Die App hat 22 Testdateien: 21 unter lib/__tests__/ und einen Smoke-Test, der die komplette App rendert. Laut CI-Commit vom 16.09.2026 liefen dort 22 Suiten mit 204 Tests grün. Statisch zählen wir 190 Testaufrufe, die Differenz erklären parametrisierte Tests mit .each. Eine Coverage-Zahl nennen wir nicht, weil keine gemessen wurde.

Getestet wird dort, wo ein Fehler teuer wäre und die Logik rein ist, also ohne Bildschirm prüfbar:

Ehrlich gesagt: UI-Screens sind nicht automatisiert getestet. Es gibt keine Snapshot-Tests und keine End-to-End-Tests mit Detox oder Maestro. Auch die native Kryptografie-Kette läuft nur auf dem Gerät, die Architekturentscheidung sagt das ausdrücklich. Das ist eine bewusste Abwägung für eine App dieser Größe in dieser Phase. Die Oberfläche haben wir auf echten Geräten, im Emulator und über eine Beta-Gruppe geprüft. Automatisierte UI-Tests wären der nächste sinnvolle Schritt, sobald sich die Screens weniger schnell ändern.

TypeScript, Lint, Fehlergrenze

Drei Skripte bilden das Qualitätstor: typecheck, lint und test. Der Release-Workflow führt Typprüfung und Tests vor jedem Build aus. Ein roter Test verhindert damit ein Release. ESLint läuft mit der offiziellen React-Native-Konfiguration und genau zwei Ausnahmen (Inline-Styles und verschachtelte Komponenten), die in der Konfiguration begründet sind. Die CI hat ein ESLint-Gate für alle Frontends der Plattform und ein zweites Gate, das verhindert, dass Geheimnisse in Frontend-Code landen.

Die Fehlergrenze ganz außen und der globale Absturz-Handler gehören für uns ebenfalls zur Qualität. Eine App, die bei einem unerwarteten Fehler weiß wird und sich still schließt, verliert Vertrauen schneller als eine, die sagt, dass etwas schiefging, und einen Knopf zum Weitermachen anbietet.

Release: Android App Bundle, Signierung, targetSdk 36, Versionierung

Für den Play Store bauen wir ein Android App Bundle (AAB), für die Beta-Verteilung über Firebase App Distribution ein APK. Beide entstehen im selben Workflow, gewählt wird das Artefakt beim Start. Die Ziel-Plattform ist targetSdk 36, die Mindestversion minSdk 24. Die New Architecture und Hermes sind aktiv, Edge-to-Edge ist eingeschaltet, was ab targetSdk 35 ohnehin Pflicht ist.

• Signierung: Die Release-Signatur kommt ausschließlich aus Werten, die nicht im Repository liegen. Nach dem Build prüft der Workflow die Signatur des Bundles aktiv und bricht ab, wenn sie nicht gültig ist.

• Versionierung: Der versionCode ist die fortlaufende Laufnummer der CI und steigt damit bei jedem Upload, wie Google es verlangt. Der versionName setzt sich aus der Version in der package.json und dieser Nummer zusammen, zum Beispiel 1.0.0 plus Build.

• Kontrolle: Vor dem Upload liest der Workflow den versionCode aus dem fertigen Bundle. Weicht er ab, bricht er ab, statt einen fremden Stand einzutragen.

• Upload: Das Bundle landet über die Publishing-Schnittstelle als Entwurf in der Produktionsspur. Ausgerollt wird es erst, wenn ein Mensch in der Play Console zustimmt.

• Schlüssellos: Die Anmeldung bei Google läuft über Workload Identity Federation. Es gibt keine Dienstkonto-Schlüsseldatei, die irgendwo liegen und verloren gehen könnte.

Wer eine App im Google Play Store veröffentlichen will, unterschätzt meist genau diese Kette. Ein sauberer Build ist das eine. Wiederholbar wird er erst, wenn Versionen automatisch steigen, die Signatur geprüft wird und niemand aus Versehen an alle Nutzer ausrollt.

Play-Konto, Prüfung und Store-Eintrag

Das Entwicklerkonto haben wir am 30.08.2026 als Organisation für myNextDays ApS angelegt, nicht als Person. Das hat einen praktischen Grund: Für neue Personenkonten verlangt Google vor dem Produktionsstart einen geschlossenen Test mit mindestens 12 Testern über 14 Tage, Organisationskonten sind davon ausgenommen. Die Test-Tracks selbst beschreibt Google unter Play Console: Test-Tracks. Zum Konto gehörten außerdem die Angaben zum Händlerstatus nach dem Digital Services Act.

Eingereicht haben wir Version 1.0.0 am 31.08.2026. Das bislang letzte Update im Store ist vom 16.09.2026. Die App steht in der Kategorie Business, der Eintrag zeigt „1+ Downloads“ und eine Einstufung „USK ab 16 Jahren“ mit dem Hinweis auf Chats. Weitere Zahlen nennen wir bewusst nicht. Den Eintrag im Google Play Store kannst du dir direkt ansehen. Ein Hinweis zur Ehrlichkeit: Teile der Store-Beschreibung stammen aus der Zeit vor dem 09.09.2026 und nennen noch Funktionen für Eigentümer. Die liegen heute in der separaten App „myNextDays Eigentümer“. Die Release-Notes des Updates sagen das korrekt.

Die sechs Store-Screenshots stammen aus einem Demo-Mandanten mit fiktiver Firma, acht Ferienobjekten, Buchungen und Aufgaben. Die Demodaten gehen nie an ein Buchungsportal, ein Schreibschutz im Backend lehnt jede Änderung ab. Damit Tester das nicht für einen Fehler halten, zeigt die App bei Demo-Konten ein festes Band: „Vorführung — ansehen ja, speichern nein.“ Die Screenshots haben wir am 30.08.2026 mit einem 1080×1920-Emulator neu aufgenommen. Die ursprünglichen iPhone-Aufnahmen mit einem Seitenverhältnis von 2,17:1 verletzten Googles Grenze von 2:1.

Zu iOS: Das Xcode-Projekt ist vollständig eingerichtet, mit Deployment-Target 15.1, Privacy Manifest, Export-Compliance-Schlüssel, App Transport Security ohne Ausnahmen und Push-Entitlement. Store-Texte und Review-Notes für Apple sind vorbereitet. Belegt ist die Veröffentlichung bisher aber nur für Google Play, deshalb behaupten wir hier nicht mehr.

Herausforderungen aus dem Projekt

Jede Case Study, die nur Erfolge zeigt, ist wenig wert. Die folgenden Probleme sind im Projekt tatsächlich aufgetreten. Jedes ist im Git-Log oder in den Architekturentscheidungen belegt.

Das Muster dahinter wiederholt sich: Die meisten Fehler zeigten sich nicht im Emulator, sondern erst unter echten Bedingungen, also beim Kaltstart nach einer Nacht, auf einem bestimmten Gerät oder beim ersten echten Release-Lauf. Deshalb haben wir so früh wie möglich eine Beta-Gruppe mit echten Geräten eingebunden, schon ab dem 19.08.2026 über Firebase App Distribution.

Nach dem Launch: Wartung, React-Native-Updates, Target-API-Anhebungen

Mit dem Store-Eintrag ist eine App nicht fertig, dann beginnt die Pflege. Google hebt die geforderte Target-API jedes Jahr an. Wer das verpasst, kann keine Updates mehr einreichen, und neue Nutzer finden die App irgendwann nicht mehr. React Native veröffentlicht regelmäßig neue Versionen, die man am besten in kleinen Schritten mitnimmt. Wer drei Versionen überspringt, hat am Ende ein Migrationsprojekt. Aktuelle Releases stehen im React-Native-Blog. Firebase-Pakete, Navigation und die nativen Module müssen dabei zusammenpassen.

Für myNextDays heißt Wartung konkret:

• React Native, React und die nativen Module aktuell halten, mit Typprüfung und Tests als Tor vor jedem Build

• Target-API und Store-Vorgaben jährlich nachziehen, einschließlich Datensicherheit und Berechtigungen

• Store-Texte mit dem tatsächlichen Funktionsumfang abgleichen, zum Beispiel nach dem Auszug des Eigentümer-Portals

• Absturzmeldungen aus dem eigenen Endpunkt auswerten und daraus gezielte Fixes ableiten

• Schwesterdateien über alle drei Apps synchron halten, die CI meldet jede Abweichung

Genau diesen Teil übernehmen wir für Kunden auch langfristig. Was dazugehört und wie wir das organisieren, steht unter Wartung und Support für Apps.

Learnings, Kosten und Zeitrahmen: was du für dein App-Projekt mitnimmst

Eine Case Study ist nur dann nützlich, wenn du daraus etwas für dein eigenes Vorhaben ableiten kannst. Deshalb fassen wir hier zusammen, was wir bei myNextDays gelernt haben, welche Entscheidungen sich bewährt haben und wo wir nachsteuern mussten. Danach ordnen wir ein, wovon die Kosten einer solchen App abhängen, wie lange die Umsetzung realistisch dauert und wann sich eine eigene Lösung überhaupt lohnt. Die Zahlen zum Projektverlauf stammen aus der Git-Historie. Die Kostenspannen sind Marktwerte zur Orientierung und keine Angaben zu diesem Projekt.

Sieben Learnings aus dem Projekt

1. Rollen früh modellieren, und zwar auf dem Server. Die App kennt sechs Rollen, vom Admin bis zur Reinigungskraft. Welche Oberfläche jemand sieht, entscheidet genau eine Stelle im Code, und die Tabs richten sich nach Berechtigungen aus der Antwort von /auth/me, nicht nach dem Rollennamen. Kommt eine unbekannte Rolle an, meldet die App den Nutzer ab, statt ins Verwalter-Dashboard zu fallen. Beträge und volle Gastnamen maskiert das Backend, die App füllt nichts auf. Hätten wir die Rechte erst am Ende ergänzt, hätten wir jeden Screen ein zweites Mal anfassen müssen.

2. Store-Compliance gehört in den ersten Sprint. Kontolöschung in der App, Datenschutzlink, Privacy Manifest, Export-Compliance, Data-Safety-Formular und Händlerstatus sind keine Formalitäten für den letzten Tag. Bei myNextDays haben wir die Angaben zur Datensicherheit vor der Einreichung Punkt für Punkt gegen das fertige Binary abgeglichen und dabei Fotos, Geräte-IDs und Absturzdaten nachgetragen. Die Screenshots mussten wir neu aufnehmen, weil die iPhone-Bilder mit einem Seitenverhältnis von 2,17:1 gegen Googles 2:1-Regel verstoßen. Wer das früh einplant, verliert beim Launch keine Tage.

3. Datenschutz ist ein Verkaufsargument. Die App enthält kein Analytics-, Werbe- oder Crash-SDK und setzt kein Tracking ein. Unter Android fragt sie nur Internet, Benachrichtigungen und Kamera an, und die Kamera nur für den Fotonachweis bei Aufgaben. Fotos kommen über den System-Picker, eine Leseberechtigung für die Mediathek braucht die App auf Android nicht. Für Vermieter, die Gastdaten verarbeiten und dafür verantwortlich sind, ist das ein handfestes Argument im Vertrieb. Es entsteht aber nur, wenn man es von Anfang an als Anforderung behandelt.

4. Web und App sprechen dieselbe API. Die App hat keine eigene Fachlogik. Sie ruft dieselbe FastAPI-Schnittstelle auf wie das Web-Dashboard und arbeitet auf demselben Datenbestand. Preise, Zahlstatus und Rechte berechnet ausschließlich der Server. Dadurch gibt es keine zweite Wahrheit, die auseinanderlaufen kann, und neue Funktionen im Web lassen sich in der App mit überschaubarem Aufwand nachziehen. Einzelne Logikteile wie das Zugriffsmodell des Posteingangs haben wir als Spiegel der Web- und Backend-Regeln umgesetzt, damit überall dieselben Regeln gelten.

5. Ein Demo-Mandant zahlt sich doppelt aus. Für die Store-Prüfung und für Vorführungen gibt es den fiktiven Betrieb „Nordlicht Ferienvermietung“ mit acht Objekten und schreibgeschützten Daten. Alle Screenshots stammen von dort, echte Gästedaten tauchen nirgends auf, und aus den Demodaten geht nie etwas an ein Portal. Eine Lektion kam aus dem Live-Betrieb: Der Schreibschutz lehnte Änderungen ab, und Nutzer hielten das für einen Fehler. Seitdem zeigt ein festes Band „Vorführung — ansehen ja, speichern nein.“ an, was los ist.

6. Store-Texte brauchen Pflege wie Code. Ein Produkt, das sich schnell entwickelt, überholt seine Store-Beschreibung. Bei myNextDays entfiel im August 2026 die In-App-Registrierung, im September zog das Eigentümer-Portal in eine eigene App um, und die Verschlüsselung des Eigentümer-Chats wanderte auf den Server. Jede dieser Änderungen macht einen Satz im Store-Text falsch. Wir halten fest, was im Code tatsächlich steht, und gleichen die Texte bei jedem Release ab. Das schützt vor enttäuschten Nutzern und vor Ärger in der Store-Prüfung.

7. Tests dort, wo die Logik sitzt. Die Testsuite umfasst laut CI-Lauf vom 16.09.2026 22 Suiten und 204 Tests. Getestet werden Token-Speicherung und Refresh, das Zugriffsmodell des Posteingangs, Zeitzonen- und Tageslogik der Aufgaben, Statusketten, Sortierung, Kontolöschung und die Absturzmeldung. Snapshot- oder End-to-End-Tests für die Screens gibt es nicht, der Schwerpunkt liegt auf der Logik in lib/. Einige Fehler fanden trotzdem erst Beta-Tester: Eine App, die morgens abstürzte, weil die Ablaufzeit des Tokens nur im Arbeitsspeicher lag, zeigte sich auf frischen Testgeräten nie. Echte Geräte im Alltag bleiben also Pflicht.

Zur Arbeitsweise gehört auch, dass wir KI-gestützt entwickeln. Mehrere Commits im Projekt tragen einen Co-Autor-Vermerk für ein KI-Modell. Architektur, Review und die Verantwortung für jede Zeile bleiben bei uns. Die KI beschleunigt vor allem Routinearbeit, Tests und Refactorings. Wie das in der Praxis aussieht und wo die Grenzen liegen, beschreiben wir im Beitrag zum Vibe Coding 2026.

Kosten einordnen: Einflussfaktoren und Marktspannen

Die ehrliche Antwort auf die Frage nach dem Preis lautet: Es hängt davon ab, was die App können muss. Bildschirme zählen dabei weniger als Rollen, Integrationen und Pflichten. Eine Verwaltungs-App wie myNextDays hat nur 21 Screen-Dateien, aber hinter jedem davon stecken Rechteprüfung, Echtzeit-Aktualisierung, Fehlerzustände und ein Backend, das alles berechnet. Die folgende Tabelle zeigt, welche Faktoren den Aufwand am stärksten treiben und wie sie sich bei myNextDays ausgewirkt haben.

Als Orientierung helfen Marktwerte, wie sie Agenturen und Ratgeber in Deutschland nennen. Ein MVP mit wenigen Kernfunktionen liegt am Markt meist bei rund 15.000 bis 25.000 €. Eine mittelkomplexe App mit Backend, mehreren Rollen und Integrationen bewegt sich eher zwischen 35.000 und 80.000 €. Die Stundensätze deutscher Entwickler liegen typischerweise bei 100 bis 180 €. Das sind grobe Marktspannen und keine Angaben zu den Kosten von myNextDays. Eine App in diesem Funktionsumfang liegt nach Marktmaßstäben eher im oberen Bereich der mittleren Spanne oder darüber, je nachdem, wie viel vom Backend schon vorhanden ist.

Hinzu kommen laufende Kosten: Hosting für das Backend, Gebühren für die Entwicklerkonten der Stores, Updates für neue Android- und iOS-Versionen und die Pflege der Abhängigkeiten. Wenn du eine App entwickeln lassen willst, frag deshalb nicht nur nach dem Preis bis zum Launch, sondern auch nach dem Aufwand im ersten Jahr danach. Einen Überblick über unsere Pakete findest du unter Preise und Pakete.

Zeitrahmen realistisch planen

Für mittelkomplexe Apps nennen Marktübersichten meist drei bis neun Monate. Wie lange es wirklich dauert, hängt weniger von der Zahl der Screens ab als davon, ob das Backend schon steht, wie klar die Rollen definiert sind und wie schnell Entscheidungen fallen. Bei myNextDays lässt sich der Verlauf der App aus der Git-Historie genau ablesen. Die folgenden Daten beziehen sich nur auf die mobile App, nicht auf die gesamte Plattform.

• 18.06.2026: erster Commit der React-Native-App, damals noch als gemeinsame App für mehrere Erlebnisse

• 13.07.2026: Matrix-Kalender, Buchungen und Nachrichten laufen

• 31.07. und 01.08.2026: Aufteilung in getrennte Apps pro Marke, neue Bundle-IDs vor der ersten Veröffentlichung

• 19.08.2026: Kontobereich mit Kontolöschung, Android-Beta über Firebase App Distribution

• 21.08.2026: Push, 2FA-Login, Passwort vergessen, Aufgaben-Kalender und Fotonachweis

• 28. bis 30.08.2026: Fehlergrenze, Absturzmeldung, Dateianhänge, Version 1.0.0

• 31.08.2026: Einreichung bei Google Play

• 09.09. bis 16.09.2026: Eigentümer-Portal in eigene App ausgelagert, Überarbeitung des Hell-Themes, Play-Update

Von der ersten Zeile bis zur Einreichung im Store vergingen also rund zehn Wochen, bis zum ersten Update im Store rund drei Monate. Allein im Ordner der Betriebs-App stehen 59 Commits zwischen dem 1. August und dem 18. September 2026. Möglich war dieses Tempo, weil das Backend parallel im selben Repository entstand und die App keine eigene Fachlogik mitbringen musste. Wer eine App für ein System plant, das es noch nicht gibt, sollte deutlich mehr Zeit einrechnen.

Für die Planung deines Projekts empfehlen wir diese Phasen:

1. Discovery: Rollen, Kernabläufe und Datenquellen klären. Welche Aufgabe erledigt wer, auf welchem Gerät, mit welchen Rechten?

2. MVP: die zwei oder drei Abläufe bauen, die im Alltag den größten Unterschied machen, bei myNextDays Kalender, Buchungen und Posteingang.

3. Beta mit echten Nutzern: Verteilung an Testgeräte, Absturzmeldungen einsammeln, Fehler aus dem Alltag beheben.

4. Store-Launch: Entwicklerkonto, Store-Eintrag, Datenschutzangaben, Screenshots und Prüfung. Mit Puffer planen, die Prüfung liegt nicht in deiner Hand.

5. Ausbau und Wartung: neue Funktionen, Updates für neue Betriebssystemversionen und die Pflege der Store-Angaben.

Wie du den Umfang eines ersten Releases sinnvoll zuschneidest, beschreiben wir ausführlich im Beitrag MVP-Entwicklung Schritt für Schritt. Für die Zeit nach dem Launch solltest du von Anfang an ein Budget einplanen. Android hebt das geforderte Target-API-Level regelmäßig an, und React Native erscheint in kurzen Abständen in neuen Versionen. Dafür gibt es unser Angebot für Wartung und Support.

Wann sich eine eigene App lohnt und wann Standardsoftware reicht

Für viele Vermieter ist eine eigene App nicht der richtige Weg. Am Markt gibt es etablierte Lösungen wie Smoobu, Lodgify, Hostaway, Guesty oder Beds24, die Kalender, Channel Manager und Nachrichten fertig mitbringen und für einzelne Ferienwohnungen oder kleine Bestände gut funktionieren. Wer seine Abläufe an ein bestehendes Produkt anpassen kann, spart Zeit und Geld. Eine eigene Entwicklung lohnt sich erst, wenn das eigene Geschäftsmodell nicht in die Standardlösungen passt oder wenn die Software selbst das Produkt ist.

Eine eigene App ist sinnvoll, wenn mindestens einer dieser Punkte zutrifft:

• Du willst die Software selbst an andere Betriebe vermarkten, wie myNextDays ApS mit seiner Plattform.

• Deine Rollen und Rechte sind feiner, als Standardtools es abbilden, etwa getrennte Sichten für Verwaltung, Reinigung und Eigentümer.

• Du brauchst eigene Kanäle wie einen Marktplatz oder eine Direktbuchungs-Website, die eng mit dem Betrieb verzahnt sind.

• Datenschutz, Hosting in der EU und Verzicht auf Tracking sind für deine Kunden ein Entscheidungskriterium.

• Du hast bereits ein Backend oder eine Web-Anwendung, und die App soll denselben Datenbestand nutzen.

Standardsoftware reicht dagegen meist, wenn du wenige Objekte selbst vermietest, deine Abläufe den üblichen Mustern folgen und du keine eigenen Funktionen vermarkten willst. Dann ist das Budget in Marketing oder Ausstattung oft besser angelegt. Wenn du unsicher bist, lohnt sich ein Gespräch, bevor du eine App entwickeln lassen oder ein Abo abschließen willst. Manchmal ist auch eine Zwischenlösung richtig: ein Standardprodukt plus einzelne automatisierte Abläufe oder eine schlanke Erweiterung über eine eigene Backend- und API-Entwicklung.

Fazit: eine Ferienwohnung-Verwaltung-App, die im Alltag besteht

myNextDays zeigt, wie eine Ferienwohnung Verwaltung App aussieht, die nicht nur im Showroom funktioniert, sondern im Alltag eines Vermietungsbetriebs. Verwalter sehen Anreisen, Belegung, Buchungen und Gästenachrichten aus mehreren Portalen an einem Ort. Reinigungskräfte bekommen nur ihre Aufgaben mit Checkliste und Fotonachweis, ohne Beträge oder Gastnamen. Eigentümer haben eine eigene App. Unter der Oberfläche sorgen serverseitige Rechte, Echtzeit-Aktualisierung, sichere Token-Speicherung und ein Verzicht auf Tracking dafür, dass die App im Betrieb verlässlich bleibt.

Die wichtigsten Bausteine waren am Ende weniger die einzelnen Features als die Grundentscheidungen: eine API für Web und App, Rollen als zentrales Modell, Compliance von Anfang an und ehrliche Store-Angaben. Diese Prinzipien lassen sich auf jede Branche übertragen, in der mehrere Rollen auf denselben Datenbestand zugreifen. Wenn du selbst eine App für Ferienwohnungsverwaltung, ein Buchungssystem oder eine andere Verwaltungs-App planst, helfen dir diese Punkte bei der Planung.

Du willst dein Vorhaben besprechen? Dann Projekt anfragen und im Erstgespräch klären wir Umfang, Rollen und einen realistischen Zeitrahmen. Mehr zu unserem Vorgehen bei der App-Entwicklung mit React Native und Flutter findest du auf der Leistungsseite, und in unseren weiteren Case Studies siehst du, wie wir andere Projekte umgesetzt haben.

Häufige Fragen zur Ferienwohnung-Verwaltung-App myNextDays

Was ist eine App zur Ferienwohnungsverwaltung?

Eine App zur Ferienwohnungsverwaltung ist der mobile Zugang zu dem System, mit dem ein Vermieter oder eine Agentur den Betrieb steuert. Sie zeigt Buchungen, Belegungskalender, Gästenachrichten und Aufgaben auf dem Smartphone, damit du auch unterwegs reagieren kannst. Bei myNextDays ist die App das Frontend einer Plattform aus PMS, Channel Manager, Direktbuchungs-Website und Marktplatz. Sie greift auf dieselbe Schnittstelle zu wie das Web-Dashboard und arbeitet mit denselben Daten. Verwalter sehen Übersicht, Kalender, Buchungen und Posteingang, Reinigungskräfte nur ihre Aufgaben. Die Rechte legt der Server fest, nicht die App.

Was ist der Unterschied zwischen PMS und Channel Manager?

Ein Channel Manager verteilt Verfügbarkeiten und Preise an Buchungsportale wie Airbnb, Booking.com oder Vrbo und holt neue Buchungen von dort zurück. Ein Property-Management-System, kurz PMS, organisiert alles rund um die Buchung: Gästedaten, Check-in und Check-out, Rechnungen, Zusatzleistungen, Reinigung und Kommunikation. Viele Vermieter nutzen zwei getrennte Produkte und müssen sie verbinden. myNextDays vereint beides auf einer Plattform. Der Kalender je Unterkunft ist dabei die einzige Wahrheit für alle Kanäle. Die App zeigt beide Seiten, also die Belegung aus allen Portalen und die operativen Abläufe wie Aufgaben und Rechnungen.

Wie vermeide ich Doppelbuchungen bei Airbnb und Booking.com?

Doppelbuchungen entstehen, wenn eine Unterkunft auf mehreren Portalen angeboten wird und die Kalender nicht schnell genug abgeglichen werden. Die sicherste Lösung ist ein zentraler Kalender, der Buchungen über eine direkte Schnittstelle mit den Portalen synchronisiert. Reine iCal-Verknüpfungen aktualisieren dagegen oft nur in Abständen und lassen Lücken. Bei myNextDays führt die Plattform je Unterkunft einen Kalender als einzige Wahrheit über alle Kanäle. In der App siehst du im Multi-Kalender alle Objekte nebeneinander, mit Kanalfarben je Buchung. Wechseltage werden als halbe Tage dargestellt, damit ein Gästewechsel nicht wie eine Doppelbelegung aussieht.

Kann ich Airbnb- und Booking.com-Nachrichten in einer App beantworten?

Ja, wenn die Software die Nachrichten der Portale in einem gemeinsamen Posteingang zusammenführt. In der myNextDays-App landen Konversationen zu Portal-Buchungen, Portal-Anfragen, Marktplatz-Nachrichten, WhatsApp und der Eigentümer-Chat in einer Liste, sortiert nach der letzten Aktivität beim Portal. Jede Konversation ist mit dem Kanal gekennzeichnet. Zum Antworten gibt es Vorlagen, einen KI-Vorschlag, eine Übersetzung, geplantes Senden und Dateianhänge. Airbnb-Anfragen lassen sich direkt annehmen oder mit einem der vom Portal erlaubten Gründe ablehnen. Wer antworten darf, regeln Berechtigungen. Ohne Antwortrecht erscheint kein Eingabefeld.

Wie organisiere ich die Reinigung meiner Ferienwohnung per App?

Am besten über Aufgaben, die einer Person zugewiesen werden und eine klare Checkliste haben. In der myNextDays-App sieht die Reinigungskraft nur ihre eigenen Aufgaben und einen Aufgaben-Kalender mit Wochenstreifen und Tagesagenda. Die Checkliste ist nach Räumen gruppiert und zeigt den Fortschritt je Raum. Zu einzelnen Punkten und zur Aufgabe selbst lassen sich Nachweisfotos mit der Kamera aufnehmen oder auswählen. Der Status läuft von offen über angenommen und in Arbeit bis erledigt. Gastnamen und Beträge bekommt die Reinigung nicht zu sehen, nur die Buchungsreferenz und die Kalendertage. Verwalter verteilen und prüfen die Aufgaben im Team-Bereich.

Gibt es eine Hotel-PMS-App, die auch für kleine Hotels passt?

Es gibt spezialisierte Hotel-PMS-Apps, viele davon mit Schwerpunkt auf größeren Häusern und englischsprachiger Oberfläche. myNextDays richtet sich laut Store-Beschreibung an Ferienhaus- und Ferienwohnungsvermieter, Agenturen und Hotels, und zu den Demo-Betrieben gehört ein kleines Hotel mit zwölf Zimmern. Das Modell aus Objekten, Buchungen, Rollen und Aufgaben lässt sich also auf kleine Häuser übertragen. Ehrlich gesagt ist die App aber vor allem für die Ferienvermietung gebaut. Funktionen wie Kassensystem, Restaurant oder klassische Rezeption gehören nicht zu ihrem Umfang. Für ein kleines Hotel lohnt sich deshalb ein genauer Abgleich der eigenen Abläufe.

Was kostet es, eine App wie myNextDays entwickeln zu lassen?

Die Kosten hängen weniger von der Zahl der Screens ab als von Rollen, Integrationen, Backend und Compliance. Als grobe Marktwerte in Deutschland gelten rund 15.000 bis 25.000 Euro für ein MVP mit wenigen Kernfunktionen und etwa 35.000 bis 80.000 Euro für eine mittelkomplexe App mit Backend und mehreren Rollen. Diese Spannen sind Orientierung und keine Angabe zu den Kosten von myNextDays. Eine Verwaltungs-App mit sechs Rollen, Portal-Anbindung, Echtzeit, Push und Store-Pflichten liegt eher im oberen Bereich oder darüber, je nachdem, ob die API schon existiert. Eine belastbare Zahl gibt es erst nach einem Gespräch über den konkreten Umfang.

Wie lange dauert die Entwicklung einer App?

Marktübersichten nennen für mittelkomplexe Apps meist drei bis neun Monate. Die Dauer hängt stark davon ab, ob das Backend schon existiert und wie klar Rollen und Abläufe feststehen. Bei myNextDays lag der erste Commit der App am 18. Juni 2026, die Version 1.0.0 wurde Ende August fertig und am 31. August bei Google Play eingereicht. Das erste Update im Store folgte am 16. September. Das entspricht rund drei Monaten für die App. Möglich war das, weil die App keine eigene Fachlogik hat und das Backend parallel im selben Repository entstand. Für die Planung solltest du Discovery, MVP, Beta und Store-Prüfung als eigene Phasen einrechnen.

Warum React Native und nicht Flutter oder nativ?

React Native erlaubt eine gemeinsame Codebasis für Android und iOS in TypeScript und nutzt dasselbe React-Wissen wie die Web-Anwendung. Für myNextDays war das ein Vorteil, weil das Web-Dashboard bereits auf React aufbaut und sich Muster, Rechte-Logik und Texte übertragen ließen. Wir setzen React Native 0.86 mit React 19, New Architecture und Hermes ein, ohne Expo. So haben wir volle Kontrolle über die nativen Projekte, zum Beispiel für Push-Kanäle und Signierung. Der native Eigencode umfasst nur 168 Zeilen Swift und Kotlin. Flutter ist technisch ebenso geeignet, passt aber schlechter, wenn Web und App dasselbe Ökosystem teilen sollen.

Ist eine Ferienwohnungs-App DSGVO-konform möglich?

Ja, wenn Datenschutz von Anfang an zur Anforderung gehört. Bei myNextDays läuft das Backend auf Servern von Hetzner in der EU, und für Gastdaten ist der Vermieter Verantwortlicher, die Plattform Auftragsverarbeiter mit einem Vertrag zur Auftragsverarbeitung, der in der App verlinkt ist. Die App enthält kein Tracking und keine Werbe- oder Analytics-SDKs. Sie fragt unter Android nur Internet, Benachrichtigungen und Kamera an. Rollen sehen nur die Daten, die sie brauchen, und die Objektkartei lädt keine Bankdaten des Eigentümers aufs Gerät. Konten lassen sich in der App löschen, Buchungsbelege bleiben wegen gesetzlicher Aufbewahrungspflicht getrennt erhalten.

Was verlangt Google Play beim Datenschutz?

Google Play verlangt ein ausgefülltes Formular zur Datensicherheit, das zu dem passen muss, was die App tatsächlich tut. Außerdem braucht jede App eine erreichbare Datenschutzerklärung. Apps mit Nutzerkonten müssen die Kontolöschung in der App und zusätzlich über einen Web-Link anbieten. Bei myNextDays haben wir die Angaben vor der Einreichung gegen das fertige Binary abgeglichen und Fotos, Geräte-IDs und Absturzdaten nachgetragen. Die Kontolöschung ist zweistufig mit Passwortbestätigung. Kontoinhaber stellen einen Antrag, der sich zurückziehen lässt, alle anderen Konten werden sofort gelöscht. Einen Web-Weg zur Löschung gibt es ebenfalls.

Brauche ich für Push-Benachrichtigungen Firebase?

Unter Android ist Firebase Cloud Messaging der Standardweg, und auch für iOS lässt sich Firebase als gemeinsame Schicht nutzen. myNextDays setzt nur die Firebase-Module für App und Messaging ein, keine Analytics und kein Crashlytics. Das Gerät meldet sein Push-Token beim Backend an und beim Abmelden wieder ab. Welche Ereignisse eine Meldung auslösen, entscheidet der Server. Tippt man auf eine Meldung, öffnet die App direkt die passende Buchung, Aufgabe oder Konversation, auch aus dem geschlossenen Zustand. Wichtig sind die Details: Android 13 verlangt eine Laufzeitberechtigung, iOS ein Push-Entitlement, sonst kommen Meldungen nicht an.

Kann eine App an ein bestehendes Verwaltungssystem angebunden werden?

Ja, wenn das System eine saubere Schnittstelle hat oder eine bekommt. Die myNextDays-App enthält keine eigene Fachlogik. Sie ruft dieselbe FastAPI-Schnittstelle auf wie das Web-Dashboard und nutzt dieselbe Anmeldung über Supabase. Preise, Zahlstatus und Rechte berechnet der Server, die App zeigt sie nur an. Das hat zwei Vorteile: Es gibt keine zweite Wahrheit, die auseinanderlaufen kann, und Änderungen im Web lassen sich in der App schneller nachziehen. Hat dein bestehendes System keine API, ist der erste Schritt meist eine API-Schicht, auf der Web und App gemeinsam aufsetzen.

Wie kommt eine App in den Google Play Store?

Du brauchst ein Entwicklerkonto, ein signiertes App-Bundle, einen vollständigen Store-Eintrag mit Beschreibung und Screenshots sowie die Angaben zu Datensicherheit, Zielgruppe und Inhalten. Danach durchläuft die App die Prüfung durch Google. Neue private Entwicklerkonten müssen vorher einen geschlossenen Test mit mindestens zwölf Testern über 14 Tage absolvieren. Für myNextDays wurde das Konto deshalb als Organisation angelegt, für die diese Pflicht nicht gilt. Die Screenshots haben wir mit einem Emulator in 1080 mal 1920 Pixeln aus dem Demo-Mandanten neu aufgenommen, damit sie Googles Vorgaben zum Seitenverhältnis erfüllen. Die Einreichung erfolgte am 31. August 2026.

Was passiert nach dem Launch (Wartung, Updates)?

Nach dem Launch beginnt die eigentliche Pflege. Android hebt das geforderte Target-API-Level regelmäßig an, React Native erscheint in kurzen Abständen in neuen Versionen, und Abhängigkeiten brauchen Sicherheitsupdates. Dazu kommen Rückmeldungen aus dem Betrieb. Bei myNextDays folgte das erste Store-Update gut zwei Wochen nach der Einreichung, unter anderem mit Korrekturen bei Push, Kontrasten und Darstellung. Weil die App kein Crash-SDK nutzt, meldet sie Abstürze anonym an einen eigenen Endpunkt. So finden wir Fehler, die Beta-Tester nicht selbst auslesen können. Plane für Wartung von Anfang an ein festes Budget pro Jahr ein.