Alte Apps ablösen

Es gibt in fast jedem Mittelstandsbetrieb eine App, über die niemand gern spricht. Sie wurde 2016 oder 2018 gebaut, sie tut ihren Dienst, und sie ist auf einer Technik gebaut, die so nicht mehr gepflegt wird oder deren Bauwerkzeuge niemand mehr im Haus hat. Xamarin, ein altes Cordova-Projekt, PhoneGap, ein Ionic der ersten Generation. Die Entwickler von damals sind weg, das letzte Update ist zwei Jahre her, und irgendwann kommt die Mail vom Store: Bitte aktualisieren Sie Ihre App.

Dieser Beitrag ist für den Moment, in dem diese Mail kommt oder der Betrieb ihr zuvorkommen will. Er erklärt, warum alte Stacks zum Problem werden, wann die kleine Lösung reicht und wann nicht, was bei einer Ablösung erhalten bleiben kann und muss, und in welcher Reihenfolge man vorgeht, damit die Nutzer am Ende einfach ein Update bekommen und nicht eine neue App suchen müssen.

Für Entscheider: Worum es geht

• Xamarin wird seit Mai 2024 nicht mehr unterstützt, PhoneGap ist seit 2020 eingestellt. Cordova selbst lebt, aber alte Cordova-Projekte hängen an Plugins und Plattformversionen, die niemand mehr pflegt.
• Der Druck ist 2026 konkret: Google Play verlangt seit dem 31. August 2026 Android 16 als Ziel für neue Apps und Updates, Apple seit April 2026 das iOS-26-SDK für Einreichungen. Eine alte App muss nicht nur laufen, ihre ganze Bauwerkzeugkette muss mit.
• Nicht jede alte App braucht eine Neuentwicklung. Xamarin.Forms hat mit .NET MAUI einen Migrationspfad, ein gesundes Ionic lässt sich oft durch einen Wechsel auf Capacitor modernisieren. Die kleine Lösung ist oft die richtige.
• Bei einer Ablösung bleibt mehr, als neu wird: Backend, Fachlogik, Store-Eintrag, Nutzer. Entscheidend sind App-Identität, Signaturschlüssel und die Daten auf den Geräten.
• Größenordnung: Eine Ablösung ist häufig deutlich kleiner als eine echte Neuentwicklung, weil Fachlogik, Backend und Betriebserfahrung bereits vorhanden sind. Wie groß der Aufwand tatsächlich ist, zeigt die technische Bestandsaufnahme. Wer den Zeitpunkt selbst wählt, wählt auch Budget und Umfang.

Warum der alte Stack zum Problem wird

Eine App ist kein Programm, das man einmal fertig baut. Sie läuft auf Betriebssystemen, die jedes Jahr neue Versionen bekommen, in Stores, die jedes Jahr neue Anforderungen stellen, und auf Werkzeugen, die gepflegt werden müssen. Bei den alten Cross-Platform-Techniken ist diese Pflege an verschiedenen Stellen weggebrochen, und zwar unterschiedlich weit:

Technik	Stand	Was das praktisch heißt
Xamarin / Xamarin.Forms	Support von Microsoft am 1. Mai 2024 beendet, Nachfolger ist .NET MAUI	Keine Sicherheitsupdates, keine Anpassung an neue iOS- und Android-Versionen. Der Umstieg auf MAUI ist eine Migration mit Werkzeugunterstützung, keine Neuentwicklung, aber auch kein Knopfdruck.
PhoneGap	Von Adobe 2020 eingestellt, inklusive PhoneGap Build	Wer auf PhoneGap Build angewiesen war, kann darüber seit Jahren keine Builds mehr erzeugen.
Apache Cordova	Wird weiter gepflegt, mit aktuellen Plattform-Releases	Nicht Cordova ist das Problem, sondern der konkrete Stack einer sechs oder acht Jahre alten Cordova-App: veraltete Plattformversionen und Plugins, deren Entwickler längst aufgehört haben. Gerade Kamera, Dateizugriff, Push, Scanner und proprietäre Hardware-Anbindungen machen die Aktualisierung aufwendig.
Ionic (alt, auf Cordova)	Ionic ist aktiv, positioniert heute Capacitor als Unterbau	Ältere Ionic-Apps tauschen den Unterbau, oft zusammen mit dem Angular-Stand darunter. Capacitor unterstützt einen Teil der bestehenden Cordova-Plugins.

Dazu kommt der Druck der Stores, und der ist kein theoretisches Zukunftsproblem. Seit dem 31. August 2026 müssen neue Apps und Updates bei Google Play Android 16 (API-Level 36) als Ziel haben. Apps mit älterem Ziel werden für neue Nutzer auf aktuellen Android-Versionen zunehmend nicht mehr angeboten, Bestandsnutzer behalten sie. Apple verlangt seit dem 28. April 2026 für Einreichungen mindestens das iOS-26-SDK. Eine alte App muss deshalb nicht nur noch auf dem Handy laufen, ihre komplette Werkzeugkette muss mit aktuellen SDKs, Store-Vorgaben und Abhängigkeiten funktionieren.

Was dabei nicht passiert: Eine App wird nicht von den Geräten gelöscht, weil sie alt ist. Aus dem Store kann sie nach Jahren ohne Update dagegen sehr wohl verschwinden, Apple räumt inaktive Apps mit wenigen Downloads aktiv ab, und Google versteckt lange nicht aktualisierte Apps ebenfalls. Was vorher passiert, ist leiser und trügerischer. Google versteckt Apps mit zu altem Ziel zunächst vor Neuinstallationen, während die Bestandsnutzer sie weiter nutzen. „Unsere Leute merken nichts" stimmt also, bis die erste neue Kollegin ein neues Handy bekommt und die App nicht findet. Ein neues Update lässt sich dann nur einreichen, wenn es die aktuelle Zielvorgabe erfüllt. Und spätestens wenn ein Betriebssystem-Update eine alte Schnittstelle abschaltet, funktioniert die App nicht mehr, ohne dass jemand sie entfernt hätte.

Das Risiko ist nicht, dass die App morgen ausfällt. Das Risiko ist, dass sie an dem Tag ausfällt, an dem Sie sie dringend anpassen müssen, und dann niemand mehr bauen kann.

Wann die kleine Lösung reicht

Nicht jede alte App braucht eine Ablösung, und ich sage das gern, auch wenn es weniger Auftrag bedeutet. Zwei Migrationspfade sind echt und oft die richtige Wahl:

• Xamarin.Forms nach .NET MAUI. Wer ein Team mit C#-Wissen im Haus hat und eine sauber gebaute Xamarin.Forms-App, hat mit dem .NET Upgrade Assistant einen unterstützten Migrationspfad auf einen gepflegten Stack, ohne die Fachlogik anzufassen. Wie viel manuelle Nacharbeit bleibt, hängt stark von Abhängigkeiten, Custom Renderern und plattformspezifischem Code ab. Das lohnt sich, wenn die App groß ist und die Mannschaft C# spricht.
• Altes Ionic nach Capacitor. Eine gesunde Ionic-App mit noch gepflegtem Angular- oder React-Unterbau kann oft auf Capacitor migriert werden, ohne den Client neu zu entwickeln. Plugins und Frameworkstand entscheiden darüber, ob daraus ein überschaubarer Unterbau-Tausch oder eine größere Modernisierung wird.

Je mehr von drei Dingen zutrifft, desto klarer wird die Ablösung günstiger als die Migration: Der Quellcode ist in einem Zustand, den niemand mehr weiterentwickeln will, die Hardware-Anbindung hängt an Plugins ohne Nachfolger, und es gibt niemanden mehr, der die Ursprungstechnik kann. Schon ein einzelnes Hardware-Plugin ohne Nachfolger kann eine Migration bei sonst sauberem Code zur Neuentwicklung in der alten Technik machen. Die Bestandsaufnahme unten entscheidet das, nicht das Bauchgefühl.

Was bei einer Ablösung erhalten bleibt

Der häufigste Denkfehler ist, eine Ablösung als Neuentwicklung zu kalkulieren. Das ist sie nicht. Bei den meisten Business-Apps bleibt mehr, als neu wird:

• Das Backend. Die Schnittstelle, gegen die die App spricht, die Datenbank, die Nutzerverwaltung. Wenn die alte App eine saubere Schnittstelle nutzt, spricht die neue gegen dieselbe. Wenn nicht, ist das Backend der erste Ort, an dem man aufräumt, bevor die App dran ist.
• Die Fachlogik. Was die App tut, ist bekannt und erprobt. Die alte App ist die beste Spezifikation, die es gibt, inklusive aller Sonderfälle, die in fünf Jahren Betrieb aufgefallen sind.
• Die Store-Präsenz. Der Eintrag im App Store und bei Google Play, die Bewertungen, die Installationen. Das alles bleibt, wenn man drei Dinge richtig macht, dazu gleich.
• Die Nutzer. Sie sollen am Ende ein Update bekommen, kein neues Icon suchen und keine neue App installieren müssen.

Neu wird der Client: die Oberfläche, die Anbindung an Kamera, Scanner, GPS oder NFC, die lokale Datenhaltung. Das ist der Teil, der am alten Stack hängt, und der Teil, den ich heute in Flutter baue, wenn die App auf beiden Plattformen laufen soll. Ob Flutter, .NET MAUI oder nativ die richtige Wahl ist, hängt vom Bestand ab, und der Beitrag über Native und Cross-Platform hilft bei der Entscheidung. Wer die App extern bauen lässt, wählt die Technik, die in fünf Jahren noch jemand kann.

Die drei Dinge, die über ein sauberes Update entscheiden

Hier liegt der Unterschied zwischen einer Ablösung, die Nutzer gar nicht bemerken, und einer, die sie verärgert. Alle drei sind technisch klein und werden trotzdem regelmäßig vergessen, weil sie nichts mit der sichtbaren App zu tun haben.

1. Gleiche App-Identität

Jede App hat eine technische Kennung: die Bundle-ID bei Apple, den Paketnamen bei Android, etwa de.musterbetrieb.inventur. Der Store erkennt eine App an dieser Kennung. Behält die neue App die Kennung, ist sie für Store und Gerät dieselbe App, und die Nutzer bekommen sie als Update. Bekommt sie eine neue Kennung, ist sie eine fremde App: neuer Store-Eintrag, keine Bewertungen, keine Installationsbasis, und auf den Geräten liegen alte und neue App nebeneinander. Die Kennung muss also von Anfang an feststehen, und sie gehört ins Pflichtenheft, nicht in die Fußnote.

2. Dieselben Signaturschlüssel, oder ein Weg zu ihnen

Bei Android ist jede App mit einem Schlüssel signiert, und ein Update wird nur installiert, wenn es mit demselben Schlüssel signiert ist. Hier lohnt sich die Unterscheidung, die in vielen Anleitungen fehlt. Läuft die App bereits mit Play App Signing, verwaltet Google den eigentlichen App-Signaturschlüssel, und die Entwicklerin lädt mit einem separaten Upload-Schlüssel hoch. Ein verlorener Upload-Schlüssel ist dann kein Weltuntergang, er lässt sich nach Identitätsprüfung zurücksetzen. Kritisch ist eine ältere App ohne Play App Signing: Fehlt dort der ursprüngliche Signaturschlüssel, kann eine neue Version nicht mehr als Update der vorhandenen App ausgeliefert werden. Das ist die erste Frage, die ich bei jeder Ablösung stelle, und erstaunlich oft die, bei der es still wird.

Bei Apple hängt die App-Identität ebenfalls an der Bundle-ID und dem App-Store-Eintrag. Liegt die App im Entwicklerkonto einer Agentur, die es nicht mehr gibt oder die man verlassen will, ist das kein verlorener Fall: Apple erlaubt die Übertragung einer App zwischen Entwicklerkonten, Bewertungen und Update-Pfad bleiben erhalten. Zu prüfen sind accountgebundene Funktionen wie Push Notifications, Keychain Sharing, App Groups oder iCloud, weil sie beim Transfer zusätzliche Schritte erfordern können. Wem Konto und Schlüssel gehören sollten und was zu tun ist, wenn die Agentur sie hat, ist ein eigenes Thema, das in einem der nächsten Beiträge dran ist.

3. Die Daten auf den Geräten

Eine Business-App speichert Dinge auf dem Gerät: Anmeldung, nicht synchronisierte Erfassungen, Einstellungen, oft eine lokale Datenbank für den Offline-Betrieb. Bei einem Update bleibt der Datenordner der App erhalten, aber die neue App muss die alten Daten finden und lesen können, und die liegen bei einer alten Cordova-App an ganz verschiedenen Orten: in einer SQLite-Datenbank, im Speicher der WebView (IndexedDB, LocalStorage), in Dateien, in Plugin-eigenen Formaten, in verschlüsselten Ablagen des Systems, oder als noch nicht hochgeladene Fotos und Belege.

Vor der Migration muss deshalb inventarisiert werden, welche Daten ausschließlich auf dem Gerät existieren, wo sie gespeichert sind und was verloren wäre, wenn sie weg sind. Erst danach lässt sich entscheiden, ob die neue App die Daten direkt weiterverwenden kann oder beim ersten Start übernehmen muss. Die Übernahme selbst ist wenig Code, aber sie muss mit echten Datenständen von echten Geräten getestet werden, nicht mit einer frischen Installation. Wer das überspringt, erfährt es von der Kollegin, deren zwanzig Erfassungen vom Vortag nach dem Update weg sind.

Ein Fall aus der Praxis, verfremdet

Eine Erfassungs-App für den Außendienst aus dem Jahr 2017, Cordova, drei Plugins ohne Nachfolger, das Backend ein direkter Datenbankzugriff. Der Keystore lag auf dem Laptop eines Entwicklers, der 2021 gegangen war; Play App Signing gab es für die App nicht. Die Ablösung stand drei Wochen still, bis der Laptop in einem Schrank auftauchte und das Passwort in einer alten Mail. Ohne beides wäre es eine neue App mit neuem Paketnamen geworden, und alle 140 Nutzer hätten sie neu installieren müssen. Die neue App wurde in Flutter gebaut, gegen eine frisch davorgesetzte API, mit einer Übernahme der lokalen Erfassungen beim ersten Start. Für die Nutzer war es ein Update. Die drei Wochen Suche waren teurer als die Übernahme der Daten.

Vorgehen in sechs Etappen

1. Bestandsaufnahme. Welche Plugins und Schnittstellen nutzt die alte App, welche davon leben noch, wie sieht das Backend aus, wo liegen Quellcode, Schlüssel und Store-Konten, welche Daten liegen nur auf den Geräten. Bei einer überschaubaren App reichen dafür oft wenige Tage. Danach steht fest: Migration, Ablösung oder beides in Etappen.
2. Backend absichern. Wenn die App direkt auf die Datenbank zugreift oder eine gewachsene Schnittstelle nutzt, wird zuerst eine saubere API davor gesetzt. Die alte App kann sie parallel nutzen, die neue wird gegen sie gebaut.
3. Neue App bauen, mit der alten als Spezifikation. Funktionsumfang: das, was tatsächlich benutzt wird. Eine Ablösung ist der beste Zeitpunkt, um Funktionen zu streichen, die seit drei Jahren niemand öffnet.
4. Parallel testen. Die neue App geht per TestFlight und internem Play-Test an eine Handvoll echter Nutzer, mit ihren echten Geräten und Datenständen. Hier fällt auf, was bei der Datenübernahme fehlt.
5. Gestuft ausrollen. Beide Stores erlauben, ein Update erst an einen Teil der Nutzer zu geben. Erst zehn Prozent, dann fünfzig, dann alle. Wie das mit Feature-Flags und Versionierung zusammenspielt, steht im Beitrag zur App-Update-Strategie.
6. Alte App abschalten. Erst wenn die Nutzung der alten Version gegen null geht, wird die alte Schnittstelle abgeschaltet. Bis dahin laufen beide, und das Backend protokolliert, welche Version noch anfragt.

Was es kostet, wie lange es dauert, und was es kostet, es nicht zu tun

Eine Ablösung ist häufig deutlich kleiner als eine echte Neuentwicklung, weil Backend, Fachlogik und die Erfahrung aus dem Betrieb bereits vorhanden sind. Wie groß der Aufwand tatsächlich ist, hängt an Hardware-Anbindung, Datenhaltung und Zustand des Backends, und genau das zeigt die technische Bestandsaufnahme. Wer die Zahlen für eine Neuentwicklung sucht, findet sie im Beitrag über App-Entwicklungskosten.

Die Frage, die der Entscheider mit der Store-Mahnung im Postfach zuerst stellt, ist aber eine andere: Wie lange habe ich? Bei einer überschaubaren Business-App lässt sich eine Ablösung häufig innerhalb einiger Wochen umsetzen. Bei komplexer Offline-Logik, Hardware-Anbindungen oder einem sanierungsbedürftigen Backend kann es deutlich länger dauern. Google kündigt neue Zielvorgaben mit Monaten Vorlauf an und gewährt auf Antrag eine Fristverlängerung, für die aktuelle Vorgabe bis zum 1. November 2026; Apple setzt seine SDK-Stichtage jedes Frühjahr mit Vorlauf. Wer beim ersten Hinweis beginnt, hat genug Zeit. Wer wartet, bis die App für neue Nutzer verschwunden ist, hat sie nicht mehr.

Die andere Seite der Rechnung wird seltener aufgemacht. Eine App auf einem verwaisten Stack hat drei versteckte Kosten: Jede Anpassung wird teurer, weil erst jemand die alte Werkzeugkette zum Laufen bringen muss. Jede Sicherheitslücke in einem verwaisten Plugin bleibt offen, und bei einer App, die personenbezogene oder geschäftskritische Daten verarbeitet, wird daraus ein konkretes Datenschutz- und Informationssicherheitsrisiko. Und der Handlungsdruck kommt von außen, ohne Rücksicht auf Budgetjahr oder Saison. Wer den Zeitpunkt der Ablösung selbst wählt, wählt auch das Budget und den Umfang. Wer ihn sich vom Store diktieren lässt, zahlt Eilzuschlag.

Die häufigsten Fehler

• Neue App-ID. Aus dem Update wird eine zweite App im Store, mit null Bewertungen und null Installationen.
• Schlüssel nicht gesucht, bevor gebaut wird. Die neue App ist fertig, und dann stellt sich heraus, dass niemand den Keystore hat.
• Datenübernahme vergessen oder nur mit frischer Installation getestet. Nutzer verlieren ihre nicht synchronisierten Erfassungen beim ersten Start.
• Große Lösung, wo die kleine reicht. Eine gesunde Ionic-App neu in Flutter bauen, statt den Unterbau zu tauschen.
• Eins zu eins nachbauen. Alle Funktionen der alten App übernehmen, auch die, die niemand nutzt.
• Backend mitreißen. Aus der App-Ablösung wird ein Gesamtprojekt, das nie fertig wird. Backend absichern ja, neu bauen nur, wenn es sein muss.
• Alle auf einmal. Ohne gestuften Rollout trifft ein Fehler in der Datenübernahme jeden Nutzer gleichzeitig.

Checkliste: Ist Ihre App reif für die Ablösung?

• ☐ Auf welcher Technik ist die App gebaut, und wird der konkrete Stack noch gepflegt?
• ☐ Lässt sich die App heute mit aktuellen SDKs bauen und einreichen?
• ☐ Erfüllt sie die aktuellen Zielvorgaben von Google Play und Apple?
• ☐ Liegen Quellcode, Signaturschlüssel und Store-Zugänge beim Betrieb, oder läuft die App über Play App Signing?
• ☐ Hat die App eine saubere Schnittstelle zum Backend, oder greift sie direkt auf Daten zu?
• ☐ Reicht eine Migration (MAUI, Capacitor), oder braucht es eine Ablösung?
• ☐ Welche Funktionen werden wirklich genutzt?
• ☐ Welche Daten liegen nur auf den Geräten, und was wäre verloren, wenn sie weg sind?

Fazit: Rechtzeitig ablösen heißt selbst entscheiden

Eine App auf Xamarin, altem Cordova oder Ionic der ersten Generation ist kein Notfall, aber ein Termin, den der Betrieb selbst setzen sollte, bevor der Store ihn setzt. Manchmal reicht die Migration, manchmal braucht es die Ablösung, und die Bestandsaufnahme sagt, was. Die Ablösung ist kleiner, als sie aussieht, wenn Backend und Fachlogik bleiben, und sie ist unsichtbar für die Nutzer, wenn App-Identität, Schlüssel und Daten von Anfang an mitgedacht werden. Genau diese drei Punkte prüfe ich als Erstes, denn sie entscheiden darüber, ob am Ende ein Update ausgeliefert wird oder eine zweite App.