App-Update oder Neubau? Alte App modernisieren: Refactoring vs. Rewrite

Der erste Arbeitstag einer App-Modernisierung sieht erstaunlich oft so aus: Die Agentur von damals existiert nicht mehr. Der Build lief zuletzt auf einem Laptop, der nicht mehr startet. Die Zertifikate sind abgelaufen, das README hat zwei Zeilen. Und im Play Store läuft seit dem 31. August eine Frist, nach der die App für Neukunden unsichtbar wird.

In dieser Lage fällt der Satz „Dann schreiben wir sie halt neu“ sehr leicht, denn ein normales App-Update scheint ohnehin nicht mehr möglich. Er beschreibt die teuerste Entscheidung, die du für deine App treffen kannst. Und manchmal die einzig richtige. Genau deshalb ist „neu schreiben oder refactoren?“ die falsche Frage. Sie zwingt dich in zwei Extreme: zwölf Monate ohne sichtbaren Fortschritt auf der einen Seite, eine Codebasis, die niemand mehr anfassen will, auf der anderen.

Den Zeitpunkt der Entscheidung bestimmen inzwischen ohnehin die App Stores.

Warum deine App jetzt ein Update braucht, ob du willst oder nicht

Eine App, die zwei Jahre lang kein Update bekommen hat, fällt zurück, weil sich der Boden unter ihr bewegt. Die Plattformen setzen die Fristen, und sie ziehen sie jedes Jahr nach.

Google verlangt seit dem 31. August 2026, dass neue Apps und App-Updates im Play Store Android 16 (API-Level 36) als Target-SDK haben. Bestehende Apps müssen mindestens API-Level 35 anvisieren, sonst sind sie für Neukunden auf aktuellen Geräten im Store nicht mehr sichtbar. Die beantragbare Verlängerung läuft am 1. November 2026 aus (Google Play, Target-API-Level-Anforderungen).

Seit dem 1. November 2025 müssen außerdem alle neuen Apps und Updates mit Target Android 15 oder höher 16-KB-Speicherseiten unterstützen, was bei nativem Code und älteren Drittbibliotheken auf Neukompilieren hinausläuft (Android Developers Blog).

Apple zieht parallel. Seit dem 28. April 2026 akzeptiert App Store Connect nur noch Builds, die mit Xcode 26 und dem iOS-26-SDK erstellt wurden (Apple Developer, Upcoming Requirements). Das klingt nach einer Kleinigkeit, bis dein Projekt auf einer Xcode-Version steht, die auf dem aktuellen macOS nicht mehr startet, und die Abhängigkeiten aus dem Jahr 2021 unter dem neuen SDK nicht mehr kompilieren.

Und dann die Frameworks selbst. Für Xamarin hat Microsoft den Support am 1. Mai 2024 eingestellt, der offizielle Weg heißt .NET MAUI (Microsoft). React Native hat seine Legacy-Architektur im Juni 2025 eingefroren, seit Version 0.82 läuft das Framework ausschließlich auf der New Architecture, und Expo SDK 55 erlaubt kein Zurückschalten mehr (Expo-Dokumentation). Wer eine React-Native-App von 2021 betreibt, steht damit vor einer Architektur-Migration jedes einzelnen nativen Moduls, kein normaler Versionssprung.

Die Frage ist also nicht, ob du ein App-Update brauchst. Die Frage ist, wie groß es ausfällt und ob du es noch selbst terminierst.

Der Mythos vom sauberen Neuanfang

Jeder Entwickler, der eine fremde Codebasis öffnet, hat denselben Reflex: Das ist Müll, das schreiben wir neu. Joel Spolsky hat diesen Reflex schon im April 2000 als den „größten strategischen Fehler, den ein Softwareunternehmen machen kann“ beschrieben (Things You Should Never Do, Part I). Sein Beispiel war Netscape, das seinen Browser komplett neu schrieb und fast drei Jahre lang keine neue Major-Version auslieferte, während Internet Explorer den Markt übernahm.

Der Kern seines Arguments gilt für Apps heute unverändert. Alter Code sieht hässlich aus, weil er funktioniert. Jede merkwürdige Sonderbehandlung ist ein Bugfix, hinter dem ein echter Nutzer mit einem echten Gerät stand.

Der Workaround für die Kamera-API eines bestimmten Samsung-Modells, das Datums-Parsing, das auf einer alten iOS-Version anders lief, der Retry, den ein Firmenkunde mit schlechtem WLAN im Lager gebraucht hat. Ein Rewrite wirft dieses Wissen weg und baut es unter Zeitdruck neu auf, inklusive der Bugs, die vor fünf Jahren schon einmal gefixt wurden.

Dazu kommt die Falle, die in jedem Rewrite-Projekt zuschlägt: Feature-Parität. Die neue App darf erst live, wenn sie alles kann, was die alte kann. Also baut das Team zwölf Monate lang nach, was es schon hat, während die alte App weiter gepflegt werden muss, weil Kunden sie benutzen. Zwei Codebasen, ein Team, null neue Features. Martin Fowler hat 2004 genau dafür den Strangler-Fig-Ansatz beschrieben, die Ablösung als Umwachsen statt als Big Bang (Strangler Fig Application). Dazu gleich mehr.

Spolsky hatte trotzdem nicht in allen Fällen recht. Es gibt Codebasen, die du nicht retten solltest. Um sie zu erkennen, muss erst klar sein, was ein Refactoring überhaupt leisten kann.

Wann ein Refactoring reicht

Refactoring heißt, das Verhalten bleibt und die Struktur ändert sich. Du tauschst Abhängigkeiten, hebst das Target-SDK, ziehst Geschäftslogik aus den Views, schreibst Tests um die Stellen, die am häufigsten brechen. Die App bleibt dabei jederzeit auslieferbar.

Das funktioniert, wenn drei Dinge zusammenkommen. Erstens lebt das Framework. Swift, Kotlin, Flutter und React Native auf der New Architecture werden gepflegt und haben einen klaren Upgrade-Pfad.

Zweitens kann dein Team den Code ändern, ohne Angst zu haben. Wenn jede Änderung an der Produktliste drei andere Screens bricht und niemand sagen kann, warum, ist das ein Rettungsfall. Drittens trägt die Architektur. Eine saubere Trennung von UI, Logik und Datenzugriff lässt sich modernisieren. Eine App, deren gesamte Geschäftslogik in den View-Controllern lebt, lässt sich nur noch verschieben.

Wartung frisst ohnehin einen großen Teil der Entwicklungszeit, in einer Umfrage von SonarSource waren es im Schnitt rund 30 Prozent (SonarSource, 2019). Refactoring entscheidet darüber, wie viel von diesem Drittel künftig produktiv ist und wie viel Flickwerk bleibt.

Für die meisten Apps ist das Refactoring der richtige Standardfall. Es ist unspektakulär, es produziert keine Pressemitteilung, und es kostet einen Bruchteil eines Neubaus. Ob deine App dafür infrage kommt, zeigt eine ehrliche Bestandsaufnahme, idealerweise durch jemanden, der den Code nicht geschrieben hat. Dieselbe Bestandsaufnahme zeigt auch, wann es nicht mehr reicht.

Wann der Rewrite unvermeidlich ist

Es gibt vier Situationen, in denen du nicht mehr refactorst, sondern neu baust.

Die erste: Das Framework ist tot. Xamarin-Apps, Cordova-Apps, React-Native-Apps auf Version 0.6x mit zwanzig nativen Modulen aus Repositories, die seit Jahren keinen Commit gesehen haben. Hier ist das „Upgrade“ ohnehin ein Rewrite der Brücke zum Betriebssystem. Dann kannst du ihn auch gleich auf einem Stack machen, der die nächsten zehn Jahre trägt.

Die zweite klingt absurd, ist aber der Fall aus dem Intro: Niemand kann die App bauen. Der Apple-Developer-Account läuft auf die private Apple-ID eines Entwicklers, der vor drei Jahren gegangen ist. Das Signing-Zertifikat ist abgelaufen, der Keystore für Android liegt auf dem Laptop, der nicht mehr startet, und die Build-Pipeline war ein Shell-Skript, das nur auf genau dieser Maschine lief.

Wenn der erste Arbeitstag der Modernisierung darin besteht, die App überhaupt zu kompilieren, geht es darum, ob die App noch dir gehört. Oft ist der Neubau dann billiger als die Archäologie.

Die dritte: Die Architektur ist der Fehler. Eine App, die als Prototyp gestartet und dann fünf Jahre lang produktiv „erweitert“ wurde, hat oft keine Schicht, an der du ansetzen kannst. Business-Logik im UI, Netzwerk-Code in den Komponenten, State in globalen Variablen. Das Refactoring würde ohnehin fast jede Datei anfassen.

Die vierte: Das Geschäftsmodell hat sich geändert. Die App war mal ein Katalog und soll jetzt bezahlen, buchen, offline funktionieren und mit dem ERP sprechen. Wenn sich der Großteil der Anforderungen ändert, modernisierst du nicht mehr, du baust ein neues Produkt. Dafür gelten die Regeln aus unserem Leitfaden zu Kosten und Ablauf der App-Entwicklung.

In allen vier Fällen ist der Rewrite nur dann die richtige Entscheidung, wenn du ihn als Produktprojekt führst. Das heißt: ein Scope, der kleiner ist als die alte App, weil ein kleiner Scope die Feature-Paritäts-Falle aushebelt. Ein MVP, das nach drei Monaten echte Nutzer hat. Und die Bereitschaft, Features zu streichen, die in den Analytics seit zwei Jahren niemand aufruft.

Der dritte Weg: die App schrittweise ablösen

Zwischen „alles behalten“ und „alles wegwerfen“ liegt der Weg, der zu den meisten Apps im Mittelstand passt: die schrittweise Ablösung nach dem Strangler-Fig-Muster. Die Würgefeige, nach der Fowler das Muster benannt hat, wächst um einen Baum herum, bis sie selbst steht und der alte Stamm verschwinden kann. Übertragen auf eine App: Neue Screens entstehen im neuen Stack, alte Screens bleiben, bis sie dran sind, und beide laufen in derselben App.

Technisch heißt das Brownfield-Integration. Ein React-Native-Screen läuft als eigener View-Controller in einer bestehenden Swift-App, ein Flutter-Modul wird als AAR in eine Kotlin-App eingebunden, und die Navigation reicht den Nutzer zwischen alt und neu hin und her. Die Fallen liegen an den Nahtstellen: Zwei Navigationssysteme müssen sich einigen, wer den Back-Button besitzt, der State muss beim Übergang sauber übergeben werden, und die App-Größe wächst, solange beide Stacks an Bord sind.

Die Reihenfolge entscheidet über den Erfolg. Du beginnst mit dem Screen, der am häufigsten geändert wird, nicht mit dem, der am einfachsten ist, weil jede Woche Arbeit im alten Stack dort verlorene Arbeit ist. Der Login, den seit 2019 niemand angefasst hat, kann warten. Die Produktdetailseite, an der jeden Sprint jemand arbeitet, wandert zuerst.

Shopify hat diesen Weg über fünf Jahre gezeigt. Ende Januar 2020 kündigte das Unternehmen an, React Native zur Basis seiner mobilen Entwicklung zu machen, und zog im April 2025 Bilanz: Screens laden im 75. Perzentil unter 500 Millisekunden, und dort, wo es um Hardware-Zugriff, Widgets mit engem Speicherbudget oder lange Hintergrundjobs geht, bleibt der Code bewusst nativ (InfoQ, April 2025).

Das Entscheidende an dieser Geschichte ist nicht die Framework-Wahl. Es ist, dass die Migration nie ein Release-Stopp war. Die Apps wurden die ganze Zeit ausgeliefert.

Die Geschichte hat seit September 2026 ein weiteres Kapitel: Shopify holt seine großen Apps zurück nach Swift und Kotlin. Die Shop-App wurde in zwölf Wochen nativ neu gebaut, die Begründung lautet, dass KI-Coding-Agenten inzwischen genug der Implementierungs-, Übersetzungs- und Testarbeit übernehmen, sodass die eine gemeinsame Codebasis als Argument nicht mehr trägt (Shopify Engineering, September 2026). Das widerspricht dem Strangler-Ansatz nicht, es bestätigt ihn. Ein Zwölf-Wochen-Rewrite ist nur möglich, wenn die alte Codebasis gesund, getestet und bis zum letzten Tag auslieferbar ist. Shopify konnte neu bauen, weil fünf Jahre lang niemand den Stillstand zugelassen hat. Und es zeigt, dass Framework-Entscheidungen eine Halbwertszeit haben. Deine Architektur sollte den nächsten Wechsel erlauben, egal welchen.

Der Ansatz hat einen Preis, und den solltest du kennen, bevor du dich dafür entscheidest. Er braucht eine saubere API-Schicht zwischen App und Backend, damit alter und neuer Screen dieselben Daten sehen. Feature-Flags gehören dazu, um neue Screens erst für zehn Prozent der Nutzer zu aktivieren; ohne sie sehen hundert Prozent deiner Kunden den Crash, den der neue Screen auf einem fünf Jahre alten Android-Gerät produziert.

Vor allem aber braucht der alte Stamm einen festen Endtermin. Fehlt der, betreibst du in drei Jahren dauerhaft zwei Stacks, mit zwei Build-Pipelines, zwei Sets an Abhängigkeiten und einem Team, das in beiden Welten zu Hause sein muss. Das ist der teuerste Zustand von allen, teurer als jeder Rewrite.

Die Entscheidung in einer Tabelle

Die drei Fragen aus der Direkten Antwort, ergänzt um Anforderungen, Release-Fähigkeit und Zeithorizont, sortieren das Gespräch mit der Geschäftsführung in zehn Minuten.

Wenn du in den meisten Zeilen in der mittleren Spalte landest, ist das der Normalfall. Die meisten Apps im Mittelstand sind weder hoffnungslos noch gesund, sie liegen dazwischen. Mit einem Code-Audit von ein bis zwei Wochen lässt sich jede Zeile der Tabelle mit Befunden statt Bauchgefühl füllen.

Welcher Stack nach der Modernisierung?

Modernisiert wird, was Updates blockiert, nicht, was auf Konferenzen gerade weniger Applaus bekommt. Eine gepflegte Kotlin- oder Swift-App ist kein Modernisierungsfall, nur weil die Agentur nebenan Flutter empfiehlt; dort ist das Refactoring auf Jetpack Compose und SwiftUI der natürliche Pfad, und die Store-Fristen sind mit einem aktuellen Toolchain-Update erledigt.

Kommt die App dagegen aus einem toten Cross-Platform-Stack, führt der Weg fast immer zu Flutter oder React Native, weil beide eine Codebasis für iOS und Android bieten und sich in bestehende native Apps einbetten lassen. Welches der beiden zu deinem Team passt, hängt vor allem von der vorhandenen Web-Kompetenz ab. Rechne dabei ein, dass KI-Coding-Agenten den Preis für zwei native Codebasen gerade senken, Shopifys Rückkehr zu Swift und Kotlin ist das erste große Beispiel dafür. Den ausführlichen Vergleich findest du in unserem Artikel Flutter vs. React Native 2026.

Häufige Fragen zur App-Modernisierung

Wie erkenne ich, dass meine App ein Update braucht, bevor der Store sie versteckt?

Drei Signale. Dein Entwickler braucht für ein Target-SDK-Update mehr als ein paar Tage, die Crash-Rate steigt nach jeder neuen OS-Version, und Abhängigkeiten im Projekt haben seit über zwei Jahren kein Release bekommen. Jedes einzelne Signal ist normal. Alle drei zusammen bedeuten, dass das nächste App-Update ein Projekt wird.

Kann ich eine App modernisieren, ohne dass Nutzer etwas merken?

Ja, und bei Refactoring und schrittweiser Ablösung sollte das sogar das Ziel sein. Nutzer sollen schnellere Screens und weniger Abstürze merken, keine neue Bedienung. Die Versuchung, mit der Modernisierung gleich das Design zu überholen, verdoppelt den Scope und verwischt, ob Probleme aus der neuen Technik oder dem neuen Design kommen.

Ist eine Progressive Web App eine Alternative zum App-Update?

Für Apps, die vor allem Inhalte anzeigen und keine tiefe Hardware-Integration brauchen, kann eine PWA die Store-Fristen komplett umgehen. Web Push funktioniert inzwischen auch auf iOS. Sobald aber Bluetooth- oder NFC-Zugriff, verlässliche Hintergrundprozesse, Kamera-Workflows oder Offline-Zahlungen zur Kernfunktion gehören, bleibt die native oder Cross-Platform-App die bessere Wahl.

Fazit: Die richtige Frage stellen

Die richtige Frage lautet: Welcher Teil der App blockiert das nächste Update, und wie lösen wir genau diesen Teil ab, ohne den Rest zu gefährden? Manchmal ist die Antwort ein Nachmittag Dependency-Updates. Manchmal ein Neubau mit kleinerem Scope. Meistens ist sie eine Reihe von Releases, in denen die neue App um die alte herumwächst, bis vom alten Stamm nichts mehr übrig ist.

Die Store-Fristen nehmen dir den Zeitpunkt der Entscheidung ab. Die Richtung bleibt bei dir. Wenn du sie nicht allein treffen willst, schauen wir uns deine App gemeinsam an: App-Entwicklung bei nextlevels.