Die Beschwerde kommt meist als Gefühl, nicht als Bug-Report. Die App ist okay. Sie funktioniert. Sie fühlt sich nur alt an, liefert langsam, und jede kleine Änderung dauert drei Wochen und macht etwas anderes kaputt.
Dieses Gefühl ist ein echtes Signal — und es verdient eine saubere Diagnose, bevor irgendjemand das Wort Neubau sagt.
Die Symptome, die wirklich auf Verfall deuten
Die meisten Apps, die sich veraltet anfühlen, leiden an einem von vier Dingen — und die brauchen unterschiedliche Antworten.
Visuelle Drift. Die App folgt einer Designsprache von vor zwei OS-Generationen. Schriften, Abstände, Navigationsmuster und Animationen sagen alle ein bestimmtes Jahr. Das ist das billigste Problem — und das am häufigsten fälschlich als Neubau-Grund diagnostizierte.
Langsame Lieferung. Jede Änderung dauert länger, als sie sollte. Bestimmte Dateien will niemand anfassen. Die Schätzungen haben sich über drei Jahre still verdreifacht. Das ist Architektur, und sie wird von allein nicht besser.
Plattform-Rückstand. Neue OS-Fähigkeiten lassen sich nicht übernehmen, weil die Codebasis älter ist als sie — und jedes Jahres-Release kostet mehr Absorption als das letzte.
Performance-Zerfall. Die App wurde mit wachsendem Funktionsumfang langsamer, der Kaltstart kroch hoch, die Absturzrate auf älteren Geräten stieg.
Nur das zweite und dritte sprechen wirklich für strukturelle Arbeit. Das erste und vierte sind meist innerhalb der bestehenden App behebbar — zu einem Bruchteil der Kosten.
Die Frage, die es entscheidet
Können Sie eine sinnvolle Änderung sicher in einem normalen Sprint ausliefern?
Wenn ja, hat die App ein UI-Problem oder ein Performance-Problem — beheben Sie die direkt. Ein Redesign auf gesunder Codebasis sind Wochen, nicht Quartale, und trägt fast kein Risiko.
Wenn nein — wenn jede Änderung Code berührt, den niemand versteht, wenn um die wichtigen Teile keine Tests stehen, wenn nur eine Person die Sync-Schicht gefahrlos anfassen kann — dann haben Sie ein Architekturproblem, und keine visuelle Arbeit der Welt behebt es.
Die Unterscheidung zählt, weil ein Neubau enorm teurer und riskanter ist, als Teams erinnern. Die App, die Sie haben, beherrscht Hunderte Randfälle aus Jahren echter Nutzung. Die meisten sind undokumentiert. Einige davon sind tragend.
Abb. — Die meisten «Wir brauchen einen Neubau»-Gespräche enden an der ersten Verzweigung.
Inkrementell schlägt Big Bang, fast immer
Wenn strukturelle Arbeit wirklich nötig ist, überlebt in der Praxis der Ansatz, Screen für Screen zu ersetzen statt alles auf einmal.
Beide grossen Cross-Platform-Frameworks lassen sich in eine bestehende native App einbetten. Sie können also einen Screen im neuen Stack neu bauen, ausliefern und alles andere in Ruhe lassen. Die Nutzer bekommen eine allmählich besser werdende App. Sie bekommen echtes Feedback zur neuen Architektur, bevor Sie das Produkt darauf verwetten.
Beginnen Sie mit einem Screen, der in sich geschlossen und risikoarm ist — eine Einstellungsseite, eine statische Inhaltsansicht — und bewusst nicht mit dem Checkout. Am ersten migrierten Screen entdecken Sie, was Ihre Build-Pipeline, Ihre Navigations-Brücke und Ihr State-Management wirklich verlangen.
Die Alternative — den Ersatz parallel bauen und umschalten — klingt sauberer und ist es meistens nicht. Zwei Codebasen heissen zwei Sätze Bugfixes, so lange es eben dauert, und die Umschaltung ist ein einzelner Moment, in dem alles funktioniert oder nicht — vor allen Nutzern gleichzeitig.
Die ehrliche Ausnahme: Ist die bestehende App klein, wirklich unwartbar oder auf einem Framework gebaut, das keine Updates mehr bekommt, kann ein sauberer Neubau billiger sein. Diese Entscheidung braucht jemanden, der den Code gelesen hat — nicht jemanden, der die Beschwerden gelesen hat.
Was es kostet — und was niemand offeriert
Neubau-Schätzungen sind aus einem Grund konsequent zu tief: Die Schätzung deckt die Features, die man sieht — die Kosten stecken in denen, die man nicht sieht.
Die undokumentierte Geschäftslogik. Der Workaround für die Eigenheit des Zahlungsanbieters. Das Retry-Verhalten, das jemand nach einer schlimmen Produktionswoche eingebaut hat. Die spezielle Art, wie der Sync Konflikte auflöst — die niemand aufgeschrieben hat und auf die sich Kunden verlassen.
Budgetieren Sie Archäologie als echte Phase. Jemand liest den alten Code und schreibt auf, was er tatsächlich tut — inklusive der Teile, die wie Fehler aussehen und keine sind. Teams, die das überspringen, liefern eine technisch überlegene App aus, die schlechtere Bewertungen bekommt als ihre Vorgängerin, weil sie Verhalten verloren hat, von dem niemand wusste, dass es wichtig war.
Das Backend braucht das Gespräch meistens dringender
Ein Detail, das viele App-Modernisierungen entgleisen lässt: Die App ist oft nicht das Älteste im Raum.
Apps, die sich veraltet anfühlen, sprechen häufig mit APIs von vor einem Jahrzehnt — geschwätzige Endpunkte, keine Paginierung, Antworten in der Form eines Screen-Layouts, das es nicht mehr gibt, Authentifizierung von vor jedem heutigen Standard. Den Client darauf neu zu bauen ergibt eine moderne App, die dieselben zwölf Aufrufe macht, um einen Screen zu rendern — und die Performance-Beschwerde überlebt den Neubau unversehrt.
Prüfen Sie das vor dem Scoping. Öffnen Sie das Netzwerk-Log während einer typischen Sitzung und zählen Sie die Requests, ihre Grössen, und wie viele Roundtrips eigentlich einer hätten sein können. Fällt die Antwort unschmeichelhaft aus, gehört ein Teil Ihres Modernisierungsbudgets auf die Serverseite — und dort ausgegeben bringt es oft eine grössere gefühlte Verbesserung als alles an der Oberfläche.
Es ändert auch die Reihenfolge. Eine API-Bereinigung kann unabhängig ausgeliefert werden, nützt der bestehenden App sofort und entschärft alles, was Sie danach bauen.
Migrieren, ohne Menschen zu verlieren
Behalten Sie die Daten. Nutzer sollen die neue Version öffnen und ihre Inhalte, Einstellungen und Historie vorfinden. Eine Migration, die jemandes Zustand zurücksetzt, ist von einem kaputten Update nicht zu unterscheiden.
Liefern Sie als Update aus, nicht als neuen Store-Eintrag. Ein neuer Eintrag wirft Ihre Bewertungen, Ihr Ranking und jeden installierten Nutzer weg. Dieser Fehler ist selten — und katastrophal.
Rollen Sie gestaffelt aus. Beide Stores unterstützen stufenweise Releases; nutzen Sie sie. Ein Absturz auf einem Nischengerät ist bei fünf Prozent ein beherrschbarer Vorfall und bei hundert ein Desaster.
Und gestalten Sie nicht alles gleichzeitig um. Nutzer tolerieren eine bessere Version der App, die sie kennen. Eine App, die völlig anders aussieht, jeden Button verschoben und die Bereiche umbenannt hat, erzeugt Support-Last und Ein-Stern-Bewertungen, die mit Codequalität nichts zu tun haben.
Ein Letztes, das vor Arbeitsbeginn vereinbart gehört: was «fertig» heisst. Modernisierungsprojekte driften, weil das Ziel ein Gefühl war statt ein Zustand. Wählen Sie etwas Messbares — Kaltstart unter zwei Sekunden, eine Änderung pro Sprint lieferbar, absturzfreie Sitzungen über einer definierten Schwelle — und hören Sie auf, wenn Sie es erreicht haben, statt wenn das Budget endet.
Auffrischen oder neu bauen ist eine Entscheidung, die wir mit Kunden anhand von Daten treffen, nicht aus Nostalgie — holen Sie sich die Einschätzung.
