App modernisieren oder neu bauen?

Die App läuft seit vier oder fünf Jahren. Sie tut, was sie soll – aber jede Änderung dauert länger als früher, das Design sieht nach seinem Baujahr aus, und die Hinweise von Apple und Google, dass etwas angepasst werden muss, häufen sich. Irgendwann stellt jemand die Frage: Reparieren wir weiter, oder bauen wir neu?

Vorab die Abgrenzung: Dieser Artikel setzt voraus, dass du Quellcode, Konten und ein Team hast. Fehlt eines davon, weil der Entwickler nicht mehr erreichbar ist, beginnt die Arbeit früher – bei der Bestandsaufnahme in „App übernehmen, wenn der Entwickler weg ist“.

Die Symptome, die zählen

Nicht jedes Alter ist ein Problem. Eine App aus 2021 kann in bestem Zustand sein, eine aus 2024 schon schwer zu pflegen. Entscheidend sind die Symptome:

• Jede Änderung ist teuer. Eine kleine Anpassung braucht Tage, weil erst etwas anderes repariert werden muss, damit das Projekt überhaupt wieder baut.
• Abhängigkeiten sind stehen geblieben. Die Bibliotheken, aus denen die App besteht, werden nicht mehr gepflegt oder sind mehrere Hauptversionen zurück – ein Update zieht eine Kette weiterer Updates nach sich.
• Die Stores mahnen. Anforderungen an Zielversionen des Betriebssystems, Berechtigungen und Datenschutz-Angaben ändern sich regelmäßig; wer ihnen hinterherläuft, verbringt die Wartung mit Pflichtübungen statt mit Verbesserung. Ein aktuelles Beispiel steht im Übernahme-Artikel.
• Abstürze häufen sich auf neuen Geräten oder Betriebssystemversionen, ohne dass jemand die Ursache eingrenzen kann.
• Das Design ist zum Hindernis geworden. Nicht, weil es alt aussieht – sondern weil Nutzer Funktionen nicht finden oder die App auf aktuellen Bildschirmgrößen bricht.

Zwei oder drei dieser Punkte gleichzeitig sind das Signal, die Frage ernsthaft zu stellen. Einer allein ist Wartung.

Drei Wege – und die Frage, die sie sortiert

Gezielt sanieren. Framework aktualisieren, Bibliotheken tauschen, den Build-Prozess wiederherstellen, Store-Anforderungen abarbeiten, die schlimmsten Absturzursachen beheben. Ziel ist eine App, die wieder sicher weiterentwickelt werden kann – kein perfektes Projekt. Der richtige Weg, wenn Struktur und Datenmodell tragen und nur die Technik darunter gealtert ist.

Schrittweise ersetzen. Die App bleibt in Betrieb, aber Bereich für Bereich wird neu gebaut und ausgetauscht – erst der Einstieg, dann der Kern, dann der Rest. Teurer als Sanierung, dafür ohne den Moment, in dem alles auf einmal umgestellt wird. Sinnvoll bei großen Apps mit vielen Nutzern, bei denen ein harter Wechsel zu riskant wäre.

Neu bauen. Manchmal die ehrlichere Antwort. Anzeichen dafür: Der Funktionsumfang ist überschaubar, sodass ein Neubau nicht mehr kostet als das Entwirren; die Framework- oder Bibliotheksversion, auf der die App aufsetzt, wird nicht mehr gepflegt und es gibt keinen Aktualisierungspfad auf eine gepflegte Version; oder das Datenmodell war von Anfang an so angelegt, dass jede neue Funktion dagegen kämpft.

Zum Sortieren nutzen wir dieselbe Faustregel wie bei der Übernahme: Kosten Sanierung und Weiterpflege deutlich mehr als die Hälfte eines Neubaus, und du sitzt danach immer noch auf altem Stand – dann lohnt es sich, den Neubau ernsthaft zu rechnen. Das ist eine Faustregel und kein Gesetz: Sie ersetzt die Rechnung nicht, sie zeigt nur, wann sich das Rechnen lohnt – und rechnen lässt sich erst nach einer Bestandsaufnahme, nicht vorher.

Was beim Neubau mitwandern muss

Ein teurer Fehler beim Neubau ist, ihn als neue App zu veröffentlichen. Dann fangen Bewertungen, Downloads und Reichweite bei null an, und jeder Nutzer muss neu installieren. Ein Neubau kann und sollte als Update der bestehenden App erscheinen – vorausgesetzt, ein paar Dinge stimmen:

• Dieselbe App-Kennung. Bundle-ID bei Apple, Paketname bei Android – sie machen die neue Version zur selben App. Apple weist darauf hin, dass sich die Bundle-ID nach dem ersten hochgeladenen Build nicht mehr ändern lässt; eine andere Kennung bedeutet einen neuen App-Eintrag (Stand 2026).
• Dieselbe Signatur. Bei Android vergleicht das System beim Update die Zertifikate der neuen mit der installierten Version und lässt das Update nur zu, wenn sie zusammenpassen; mit einem anderen Zertifikat braucht die App laut Android-Dokumentation einen anderen Paketnamen. Nutzt deine App Play App Signing, verwahrt Google den App-Signaturschlüssel, und ein verlorener Upload-Schlüssel lässt sich in der Play Console zurücksetzen; verwaltest du den Signaturschlüssel selbst und er ist weg, ist der Weg deutlich schwieriger (Stand 2026). Was für deine App gilt, klärt der Übernahme-Artikel.
• Die Daten der Nutzer. Was auf dem Gerät oder auf dem Server liegt, muss die neue Version lesen oder beim ersten Start übernehmen können. Diese Migration ist eigener Aufwand und wird gern vergessen.
• Die Konten. Login-Daten, Abos, Käufe – all das muss weiter funktionieren, ohne dass Nutzer sich neu registrieren.

Wer diese vier Punkte im Angebot nicht sieht, sollte nachfragen › „Woran du ein seriöses App-Angebot erkennst“.

Die Gelegenheit, Grundsatzfragen neu zu stellen

Ein Neubau ist der Moment, in dem Entscheidungen von vor fünf Jahren nicht mehr gelten müssen. Zwei Fragen lohnen sich besonders: Nativ oder Cross-Platform? Wer zwei getrennte Apps für iOS und Android pflegt, kann beim Neubau auf eine Codebasis wechseln und Änderungen danach einmal statt zweimal umsetzen – die Abwägung steht in „Nativ oder Cross-Platform?“, der Vergleich der beiden großen Werkzeuge in „Flutter oder React Native?“. Und welche Funktionen braucht es überhaupt noch? Alles, was in fünf Jahren niemand genutzt hat, muss nicht mit umziehen.

Was das kostet

Die Bestandsaufnahme, auf der alles aufbaut, rechnen wir nach Aufwand mit 90 € pro Stunde ab; ihr Umfang hängt am Zustand des Projekts. Für einen Neubau gelten die üblichen Positionen: ein eng geschnittener Kern ab 9.900 € netto als Starter-App, ein typisches Projekt mit Konten und Backend bei 33.000–56.000 € – den Rahmen für dein Vorhaben liefert der App-Kosten-Rechner. Und egal welcher Weg: Danach gehört die App in eine geregelte Wartung, damit die Frage nicht in fünf Jahren wieder auf dem Tisch liegt › „Was in einen App-Wartungsvertrag gehört“, Kosten im Betriebskosten-Rechner. Alle Preise netto zzgl. Umsatzsteuer – unser Angebot richtet sich an Unternehmen, Selbstständige und Organisationen.

Fazit

Alter ist kein Grund, Symptome sind es. Zwei bis drei davon rechtfertigen die Bestandsaufnahme; die entscheidet zwischen Sanierung, schrittweisem Ersatz und Neubau. Und ein Neubau ist ein Update, keine neue App – wenn Kennung, Signatur, Daten und Konten mitwandern.

Wenn du die Symptome bei deiner App wiedererkennst: Im kostenlosen Erstgespräch schauen wir gemeinsam drauf. Wir antworten werktags innerhalb von 24 Stunden – auch wenn die Antwort lautet, dass eine Sanierung reicht.