Was passiert ohne App-Wartung?

Eine ungewartete App stirbt nicht plötzlich. Sie zerfällt in Etappen, und jede ist ein Stück teurer zu reparieren als die davor. Die Reihenfolge ist in den Rescue-Projekten der letzten Jahre erstaunlich konstant. Wer den eigenen Stand entlang dieser Phasen einordnet, sieht, ob die App noch im günstigen Reparatur-Fenster liegt — oder schon nicht mehr.

Phase 1: Die ersten drei Monate — leiser Drift

In den ersten 90 Tagen passiert nach außen wenig. Intern aber:

• Library-Versionen, die du eingebaut hast, fallen aus dem Support-Fenster. Die Kommunikation läuft nur über Release-Notes, die niemand liest.
• Erste CVEs werden veröffentlicht, ohne dass jemand sie patcht. Laut BSI-Lagebericht IT-Sicherheit 2025 erscheinen täglich rund 119 neue CVEs — die Lücken sitzen fast immer in transitive Dependencies, also in Bibliotheken, die nie direkt eingebaut wurden.
• Die Personen, die das System gebaut haben, verschieben den Kontext aus dem Kurzzeitgedächtnis. Sechs Monate später dauert jeder Eingriff doppelt so lang, weil zuerst Re-Onboarding nötig ist.

Sichtbarer Schaden: keiner. Risiko: aufgebaut.

Phase 2: Drei bis sechs Monate — die Reibung beginnt

Jetzt zeigen sich die ersten Symptome:

• Crashes nehmen zu, weil ein OS-Update auf Nutzergeräten Inkompatibilitäten triggert. Bei einer App ohne Crash-Reporting bemerkst du das erst, wenn jemand sich beschwert.
• Login-Probleme häufen sich, oft wegen Zertifikats- oder OAuth-Token-Ablauf. Externe Dienste rotieren, deine App nicht.
• Push-Notifications fallen aus — Apple-Push, Firebase, eigene Endpoints. Erst geräuschlos, dann hart.
• Die Store-Builds funktionieren nicht mehr lokal, weil Xcode oder Android Studio inkompatibel zur damaligen Toolchain sind. Eine kleine UI-Änderung wird zur dreitägigen Aktion.

Reparieren ist hier noch günstig: die Library-Sprünge sind klein, die Tests laufen meist noch. Wer in dieser Phase Wartung aufnimmt, kommt mit zwei bis drei Monaten Wartungsaufwand zurück in den grünen Bereich.

Phase 3: Sechs bis zwölf Monate — Compliance bricht

Hier wird es teuer:

• iOS- oder Android-Major-Release kommt, die App ist nicht migriert. Sie funktioniert teilweise oder zeigt Layout-Brüche. Das ist die Grenze, ab der Nutzer:innen aktiv abwandern.
• App-Store-Pflichten ändern sich. Apple verlangt ein aktuelles Privacy-Manifest für SDKs, die personenbezogene Daten verarbeiten — Pflicht für Submissions seit Frühjahr 2024. Google Play schreibt im jährlichen Rhythmus eine neue Target-SDK-Version als Mindest-Anforderung vor; wer sie verpasst, bekommt zunächst Updates blockiert.
• DSGVO-Drift: ein Auftragsverarbeiter wechselt Sub-Dienstleister, ein Library-Update entfernt eine Datenschutz-relevante Konfiguration. Ohne Pflege der Datenschutzerklärung läuft die juristische Lücke mit. Mehr dazu im Sub-Guide DSGVO-Wartungspflichten für Apps.

Reparieren ist jetzt deutlich teurer: die kumulierten Major-Sprünge brauchen Test-Pfade, die in der ungewarteten App fehlen. Typische Rescue-Aufwände aus unserer Praxis: vier bis acht Wochen Entwickler-Zeit für eine mittelgroße App.

Phase 4: Zwölf Monate plus — Store-Removal-Risiko

Wenn deine App in der vierten Phase angekommen ist:

• Apple und Google entfernen Apps, die Mindest-Anforderungen unterschreiten. Apples App-Store-Improvements-Programm markiert Apps, die längere Zeit ohne Update geblieben sind, und gibt eine Frist zur Aktualisierung. Google Play blockiert Updates und perspektivisch die Sichtbarkeit für Apps, die das aktuelle Target-SDK-Niveau nicht erreichen.
• Bestehende Installationen funktionieren noch, neue können nichts mehr installieren. Die Reichweite friert ein, dann schrumpft sie mit jeder Nutzer-Geräte-Migration.
• Re-Submission ist möglich, aber teuer: Major-Migrations, Privacy-Manifest-Konformität, neue Build-Toolchain. Rescues von 12-Monats-untouched-Apps kosten in Summe nicht selten so viel wie der ursprüngliche Build.

Die Frage ist hier nicht mehr „Wartung oder Rescue?”, sondern „Rescue oder Neubau?”. Den Punkt triffst du nicht plötzlich — du gleitest hinein.

Anonymisierte Praxisbeispiele

• B2C-App, 40 k Nutzer:innen, drei Jahre ungewartet. Die App lief noch, aber die letzte Build-Pipeline funktionierte nicht mehr. Eine simple Logo-Änderung kostete 12 Tage Toolchain-Restoration, bevor jemand am Logo arbeiten konnte.
• B2B-Plattform, sechs Monate ungewartet nach Agentur-Wechsel. Ein Apple-Pflicht-Update zur Privacy-Manifest-Konformität wurde verpasst. Die App war drei Wochen aus dem Store, der Auftraggeber verlor seinen größten Kunden.
• Internes Tool, 18 Monate ungewartet. Der OAuth-Provider hatte rotiert, niemand hatte die Migration durchgeführt. Login funktionierte nur noch für Bestandsuser:innen mit gültigen Tokens; Neuregistrierungen waren broken.

Was kostet ein Rescue?

Faustregel aus den letzten Rescue-Projekten: der Aufwand verdoppelt sich grob alle sechs Monate, in denen Wartung ausfällt. Eine App, die nach drei Monaten zurück ins Wartungsfenster geholt wird, kostet etwa ein bis zwei Monatswartungspauschalen. Nach einem Jahr sind es sechs bis zwölf, nach zwei Jahren oft mehr als der ursprüngliche Build.

Wenn du dich gerade in Phase 2 oder 3 wiedererkennst: das ist die letzte günstige Gelegenheit, ein AppCare aufzunehmen. Die Tarif-Logik und die Treiber dahinter stehen im Sub-Guide Was kostet App-Wartung?. Wenn du in Phase 4 bist: schreib uns über das Kontaktformular, wir gehen mit dir durch, ob ein Rescue oder ein Neubau die bessere Option ist. Antwort in 24 Stunden, ohne Sales-Pipeline.