App-Wartung: Wenn Apple und Google die Frist setzen

Es gibt einen Satz, den wir bei Erstgesprächen erstaunlich oft hören: „Die App läuft doch.” Und meistens stimmt das sogar — im Moment. Das Problem ist, dass „läuft” bei mobilen Apps kein Zustand ist, sondern eine Momentaufnahme. Apple und Google setzen jedes Jahr neue Fristen, und wer sie verpasst, verschwindet aus dem Store. Nicht mit Vorwarnung im Tagesgeschäft, sondern mit einer E-Mail an eine Adresse, die vielleicht niemand mehr liest.

Die Kurzfassung: Google verlangt regelmäßig ein aktuelles Target-API-Level, Apple einen Build gegen ein aktuelles SDK. Wer die Frist verpasst, darf zuerst keine Updates mehr einreichen, verschwindet dann aus der Store-Suche und am Ende ganz aus dem Store. Bestandsnutzer behalten die App, neue Kunden gibt es nicht mehr.

Dieser Artikel erklärt, was hinter den Fristen steckt, was tatsächlich passiert, wenn man sie reißt, und warum die Rechnung für aufgeschobene Wartung immer kommt — nur später und größer.

Target API Level und Mindest-SDK: was die Stores verlangen

Beide Plattformbetreiber verlangen regelmäßig, dass Apps gegen eine aktuellere API-Version gebaut werden. Google nennt das Target-API-Level, Apple verlangt einen Build mit einem aktuellen SDK. Welche Werte gerade gelten und ab welchem Stichtag, veröffentlichen beide Plattformen selbst — die Zahlen ändern sich jährlich, das Prinzip nicht. Die Logik dahinter ist nachvollziehbar: Neue Sicherheits- und Datenschutzmechanismen greifen nur, wenn eine App sie überhaupt kennt. Eine App, die gegen ein sechs Jahre altes System gebaut wurde, umgeht ganz selbstverständlich Berechtigungsdialoge, die es damals noch nicht gab.

Für dich als Betreiber bedeutet das etwas Unangenehmes: Deine App altert, auch wenn du nichts tust. Der Code bleibt gleich, aber die Umgebung um ihn herum verändert sich — und irgendwann ist die Differenz zu groß.

Die Konsequenzen sind gestaffelt, und genau das macht sie tückisch:

• Zuerst darfst du keine Updates mehr einreichen. Die App bleibt im Store, aber du kannst nichts mehr ändern. Auch keinen Fehler beheben.
• Dann verschwindet sie aus der Suche. Bestandsnutzer behalten sie, neue finden sie nicht mehr.
• Am Ende ist sie weg. Wer das Gerät wechselt, bekommt sie nicht wieder.

Zwischen Stufe eins und Stufe drei liegen Monate. Das reicht — wenn jemand hinschaut. Das Tückische ist die erste Stufe: Sie tut nicht weh. Niemand beschwert sich, die App läuft weiter, und die einzige Rückmeldung ist eine E-Mail an die Entwickler-Adresse aus dem Store-Konto. Wenn diese Adresse zu einem Dienstleister gehört, der das Projekt vor zwei Jahren abgeschlossen hat, liest sie niemand.

Was in der Zwischenzeit noch passiert

Die SDK-Fristen sind nur der sichtbarste Teil. Parallel läuft anderes weiter:

Betriebssystem-Updates ändern Verhalten. Ein neues iOS verschärft, wann eine App im Hintergrund arbeiten darf. Ein neues Android ändert, wie Dateizugriffe funktionieren. Dein Code ist unverändert korrekt und tut trotzdem plötzlich etwas anderes.

Abhängigkeiten laufen aus. Jede App nutzt fremde Bibliotheken. Die werden gepflegt — oder eben nicht. Eine Bibliothek, die seit zwei Jahren keinen Commit gesehen hat, ist kein stabiler Baustein, sondern eine Wette.

Zertifikate und Schlüssel verfallen. Push-Zertifikate, Signaturschlüssel, API-Tokens. Nichts davon meldet sich vorher.

Backends ziehen um. Der Dienst, den deine App anspricht, stellt eine API-Version ab. Deine App weiß davon nichts und zeigt einen leeren Bildschirm.

Keiner dieser Punkte ist dramatisch, solange jemand sie im Blick hat. Zusammen und unbeobachtet ergeben sie den Zustand, den wir bei Übernahmen regelmäßig vorfinden: eine App, die seit anderthalb Jahren kein Release hatte und bei der niemand mehr sicher sagen kann, ob sich der Build überhaupt noch bauen lässt.

Warum Nichtstun teurer ist als Pflegen

Der Reflex ist verständlich: Die App funktioniert, es gibt keine Beschwerden, also gibt es Dringenderes. Nur ist das eine Rechnung, die aufgeschoben wird, nicht eine, die entfällt.

Der Unterschied liegt im Aufwand pro Schritt. Ein Framework-Upgrade über eine Hauptversion ist eine überschaubare Aufgabe: Änderungen lesen, anpassen, testen, ausliefern. Ein Upgrade über vier Hauptversionen ist etwas anderes — nicht viermal so groß, sondern deutlich mehr. Zwischenstände lassen sich nicht mehr einzeln testen, Fehlerursachen nicht mehr zuordnen, und die Bibliotheken, auf die du zusteigen willst, haben sich in der Zwischenzeit gegenseitig inkompatibel weiterentwickelt.

Dazu kommt ein Effekt, der in keiner Kalkulation auftaucht: Wer eine App zwei Jahre nicht angefasst hat, hat auch das Wissen darüber verloren. Die Leute, die sie gebaut haben, sind woanders. Die Entscheidungen von damals sind nicht dokumentiert. Was als Wartungsstau begann, ist zu einem Rechercheprojekt geworden.

Bei einer App, die wir aus einem instabilen Zustand übernommen haben, sind über zwei Jahre acht Framework-Upgrades im laufenden Betrieb gelaufen — jedes einzelne unspektakulär, weil keins aufgeschoben wurde. Genau das ist der Punkt: Laufende Pflege besteht aus lauter kleinen, langweiligen Schritten. Aufgeschobene Pflege besteht aus einem großen, teuren.

Ein Rechenbeispiel, das wir regelmäßig sehen

Eine App aus 2021, seitdem zweimal notdürftig angefasst. Der Auftraggeber möchte ein neues Feature — eine Kleinigkeit, zwei Tage Arbeit. Was tatsächlich passiert:

Bevor irgendjemand das Feature bauen kann, muss die App sich erst wieder bauen lassen. Die Entwicklungsumgebung von damals gibt es nicht mehr in der Version. Die Signaturschlüssel liegen bei einem ehemaligen Mitarbeiter. Drei Bibliotheken haben Sicherheitswarnungen, eine davon hat keinen Nachfolger. Das Framework braucht vier Hauptversionen Sprung, und dazwischen hat sich die Art geändert, wie Navigation funktioniert — was quer durch die App Anpassungen bedeutet.

Aus zwei Tagen werden drei Wochen. Das Feature selbst kostet immer noch zwei Tage; der Rest ist nachgeholte Wartung, die vorher niemand bezahlt hat. Sie war nie umsonst, sie stand nur nicht auf der Rechnung. Ab einem gewissen Punkt ist das keine Wartungsfrage mehr, sondern die Frage, ob man saniert oder neu baut.

Was gute Wartung eigentlich umfasst

„App-Wartung” klingt nach Reparatur, ist aber überwiegend Vorsorge. Was dazugehört:

Beobachten, bevor Nutzer sich melden. Abstürze laufen in ein Monitoring, nicht in eine Ein-Stern-Bewertung. Der Unterschied zwischen „wir haben es bemerkt” und „ein Kunde hat es gemeldet” ist der Unterschied zwischen einem Bugfix und einem Reputationsschaden.

Die Fristen kennen, bevor sie greifen. Wann welche Store-Anforderung fällig wird, ist öffentlich. Es muss nur jemand nachhalten — und zwar früh genug, dass die Anpassung in einen normalen Release passt.

Regelmäßig ausliefern, auch ohne Anlass. Eine App, die alle paar Wochen ein Release sieht, hat eine funktionierende Auslieferungskette. Eine App, die einmal im Jahr released wird, hat beim ersten Versuch garantiert ein Problem mit Zertifikaten, Signaturen oder Store-Metadaten.

Bewertungen lesen. Nicht wegen der Sterne, sondern wegen der Inhalte. Wiederkehrende Beschwerden sind Fehlerberichte in Alltagssprache. „Stürzt beim Speichern ab” in drei Bewertungen derselben Woche ist ein Hinweis, den kein Monitoring so klar liefert. Wie daraus ein verwertbarer Befund wird, steht in Store-Bewertungen als Frühwarnsystem.

Abhängigkeiten im Blick behalten. Welche Bibliothek wird noch gepflegt, welche nicht? Diese Frage einmal im Quartal zu stellen, kostet eine Stunde. Sie nicht zu stellen, kostet irgendwann eine Portierung.

Die Auslieferungskette warm halten. Zertifikate, Signaturen, Store-Metadaten, Build-Server — jedes Teil davon verfällt oder ändert sich. Der einzige verlässliche Test ist ein echtes Release.

Woran du erkennst, dass es Zeit ist

Ein paar Fragen, die sich ohne technisches Wissen beantworten lassen:

• Wann wurde deine App zuletzt im Store aktualisiert? Steht auf der Store-Seite, ist öffentlich einsehbar.
• Weißt du, ob sie sich heute noch bauen lässt — nicht theoretisch, sondern tatsächlich?
• Gibt es jemanden, der bemerkt, wenn die Absturzrate steigt?
• Wer ist zuständig, wenn nächste Woche ein Push-Zertifikat abläuft?

Wenn eine dieser Fragen offenbleibt, ist das kein Notfall. Aber es ist der Zeitpunkt, an dem sich Handeln noch günstig anfühlt.

Der ehrliche Teil

Nicht jede App braucht ein monatliches Betreuungspaket. Eine interne App mit fünfzig Nutzern und ohne Store-Präsenz hat andere Anforderungen als ein Produkt, das zum Verkauf gehört. Wenn wir zu dem Schluss kommen, dass sich laufende Betreuung für dich nicht lohnt, sagen wir das — dann ist ein einmaliges Update das Richtige, und danach ist wieder Ruhe.

Was wir nicht empfehlen: abwarten, bis die E-Mail von Apple kommt. Zu diesem Zeitpunkt ist die Frist nicht mehr verhandelbar, und der Aufwand steht nicht mehr zur Diskussion.

---

Passend dazu: Wir übernehmen Betrieb und Wartung bestehender Apps — auch für Apps, die wir nicht gebaut haben. Wie das abläuft, steht auf der Seite zur App-Pflege.