App-Wartung und Support: Die Fristen setzen Google und Apple
App-Wartung und Support folgt einem fremden Kalender
Google Play nennt für veröffentlichte Apps einen festen Stichtag. Seit dem 31. August 2026 muss eine Bestandsapp mindestens Android 15 als Zielversion ansprechen, sonst verschwindet sie auf neueren Geräten für neue Nutzer aus dem Store.
App-Wartung und Support umfasst alle Leistungen, die eine mobile Anwendung nach der Veröffentlichung lauffähig und verteilbar halten. Dazu gehören Sicherheitsupdates für eingesetzte Bibliotheken, die Anpassung an neue iOS- und Android-Versionen, die Einhaltung der Store-Vorgaben von Apple und Google, das Beheben gemeldeter Fehler sowie die Betreuung der Anwender bei Störungen.
Was die Wartung mobiler Apps von Serverpflege trennt
Nach der App-Entwicklung unterscheiden sich zwei Betriebsarten deutlich voneinander. Bei Software im eigenen Rechenzentrum legt der Betrieb sein Wartungsfenster selbst. Die Wartung mobiler Apps kennt diese Freiheit nicht, weil zwei Plattformbetreiber und die EU über die Verteilung bestimmen. Ein Update erreicht die Anwender erst, wenn Apple oder Google es annehmen, und geprüft wird die Einhaltung jährlich wechselnder Vorgaben. Aus der Entwicklung wird damit eine App-Wartung mit festen Terminen statt einer App-Betreuung auf Zuruf. Selbst bei eingehaltener Frist kann ein fertiges Update liegen bleiben, und die Gründe dafür stehen im Abschnitt Warum scheitert ein Update trotz fertiger App.
Google Play und das Target-API-Level
Das Target-API-Level ist die Android-Version, für die eine App gebaut wurde. Google Play verlangt seit dem 31. August 2026 für neue Apps und Updates Android 16, für Bestandsapps mindestens Android 15. Eine App darunter geht nicht verloren, sie wird unauffindbar. Auf neueren Android-Geräten sehen neue Nutzer sie nicht mehr, installierte Kopien laufen weiter. Eine Fristverlängerung bis zum 1. November 2026 lässt sich in der Play Console beantragen, sie verschiebt den Termin und nicht die Pflicht.
Apple und die SDK-Pflicht
Apple setzt eigene Termine, die nicht mit denen von Google zusammenfallen. Seit dem 28. April 2026 nimmt App Store Connect nur Uploads an, die mit dem iOS-26-SDK und Xcode 26 gebaut wurden. Eine App an eine neue iOS-Version anpassen bedeutet dabei nicht, ältere Geräte auszuschließen, denn darüber entscheidet das Deployment Target. Seit dem 31. Januar 2026 blockieren zudem fehlende Angaben zur Altersfreigabe jedes weitere Update.
Diese Termine gelten unabhängig vom Zustand der Anwendung:
❗ 31. August 2026: Bestandsapps mindestens Android 15
❗ 31. August 2026: neue Apps und Updates Android 16
❗ 1. November 2026: Ende der Fristverlängerung
❗ 28. April 2026: Uploads nur mit iOS-26-SDK
❗ 31. Januar 2026: Angaben zur Altersfreigabe
Was App-Wartung und Support zur Pflicht macht
Neben den Store-Fristen läuft ein zweiter Strang, der sich nicht terminieren lässt. Das BSI zählte für das erste Quartal 2026 10.806 Schwachstellen, nach 10.702 im Vorquartal. Ein Teil steckt in den Bibliotheken, aus denen jede App zusammengesetzt ist. Ein veraltetes Grafik- oder Netzwerkmodul öffnet dieselbe Lücke wie eine unsichere eigene Codezeile. Bei einer gemeinsamen Codebasis wie in der hybriden App-Entwicklung wirkt sie auf beiden Plattformen, was Wartung und Support von Apps beschleunigt.
Was ist Pflicht, was ist Weiterentwicklung?
Die Trennung entscheidet über das Budget der App-Wartung, und sie fällt schärfer aus als in vielen Angeboten. Pflicht ist alles, was eine App verteilbar und sicher hält, also Store-Fristen, Sicherheitsupdates und die vorgeschriebenen Angaben. Weiterentwicklung ist alles, was Funktionen hinzufügt oder Abläufe umbaut. Innerhalb der Pflicht unterscheidet die Norm ISO/IEC 14764 zwischen korrektiver, adaptiver, präventiver und perfektionierender Softwarewartung. Pflichtaufgaben lassen sich nicht verschieben, Erweiterungen schon, und daran hängt die Planbarkeit der App-Wartungskosten.
Diese Aufgaben fallen in jeder App-Wartung an, unabhängig von neuen Funktionen:
- Sicherheitsupdates für Bibliotheken und Frameworks
- Anheben von Target-API-Level und Build-SDK
- Nachziehen der geforderten Store- und EU-Angaben
- Erneuern ablaufender Zertifikate und Signaturschlüssel
- Beheben gemeldeter Abstürze und Fehler
Wartung mobiler Apps im Jahresrhythmus
Der Takt der Plattformen ist vorhersehbar und macht die App-Wartung planbar. Apple und Google zeigen neue Systemversionen im Sommer als Vorabfassung und veröffentlichen sie im Herbst. Ein Prüflauf im Juli oder August findet Probleme, bevor Anwender sie melden, und verschiebt Wartung und Betrieb von Individualsoftware von der Reaktion in die Vorsorge. Weil Android in Deutschland 74,5 Prozent des Smartphone-Absatzes ausmacht, trifft ein Android-Fehler die Mehrheit der Anwender. Zwei Systeme bedeuten zwei Prüfläufe im Jahr.
Woran App-Support in der Praxis scheitert
Wartung und Support mobiler Apps enden nicht beim Code, sondern bei den Zugängen. App-Support beginnt beim Anwender, die Ursache liegt im Code, und die Behebung braucht einen Store-Release. Genau an dieser letzten Stelle bleiben Vorgänge liegen, weil der Weg in den Store an Konten und Schlüsseln hängt, die niemand pflegt. App-Monitoring verkürzt die erste Hälfte dieser Kette, indem Abstürze und Ladezeiten gemeldet werden, bevor eine Beschwerde eintrifft. Die zweite Hälfte gehört zum App-Support und lässt sich nur organisatorisch lösen.
Diese Zugänge gehören dokumentiert und intern hinterlegt:
- Entwicklerkonto bei Apple und Google Play
- Signaturschlüssel und Keystore der Android-App
- Verteilungszertifikate und Profile für iOS
- Zertifikate für Push-Nachrichten
- Konten für Absturzberichte und App-Monitoring
Warum scheitert ein Update trotz fertiger App?
Der häufigste Grund ist ein abgelaufenes Zertifikat oder ein Konto, dessen Verlängerung niemand bemerkt hat. Läuft ein Verteilungszertifikat oder die Mitgliedschaft im Entwicklerprogramm aus, lässt sich der fertige Build nicht mehr signieren. Bei einem Wechsel kommt der Streit um die Kontoinhaberschaft hinzu, weshalb Konten und Schlüssel in jede Auswahl eines App-Dienstleisters gehören. Der Quellcode allein reicht für ein Update nicht, denn ohne Kontozugang findet er keinen Weg in den Store. App-Wartung und technischer Support brauchen beides, Code und Schlüssel.
Welche Angaben verlangt die EU für Apps?
Der Digital Services Act verlangt von gewerblichen Anbietern einen verifizierten Händlerstatus, und Apple setzt das seit dem 17. Februar 2025 durch. Fehlt der Status, wird die App aus dem Store entfernt, und zwar EU-weit, bis die Prüfung durchlaufen ist. Für App-Updates gilt die Bedingung seit dem 16. Oktober 2024. Die Vorgabe ist keine Technikfrage, sondern eine Angabe im Konto, und fällt deshalb hinten herunter. Store-Compliance ist eine kaufmännische Aufgabe, weshalb App-Support und App-Wartung hier auf die Verwaltung angewiesen sind.
Wenn Aktualisieren nicht mehr genügt
Irgendwann übersteigt der Aufwand für das Nachholen den Aufwand für einen Neubau. Das passiert selten plötzlich, sondern dann, wenn das eingesetzte Framework kein Update mehr erhält und sich deshalb keine App an eine neue iOS-Version anpassen lässt. Dann führt kein Weg über die App-Wartung, sondern über die App-Modernisierung, und diese Entscheidung fällt vor dem nächsten Stichtag. Wurde eine App aus dem Store entfernt, kostet die Rückkehr zusätzlich Prüfzeit.
Vier Anzeichen sprechen für einen Neubau statt weiterer App-Wartung:
- Sicherheitsupdates der Bibliotheken sind nicht verfügbar
- Zwei Systemwechsel wurden übersprungen
- Abstürze steigen nach jedem Systemupdate
- Niemand kennt die Abhängigkeiten der Anwendung
Vom Rückstand zur Entscheidung
Die Bestandsaufnahme vor dieser Entscheidung fällt kleiner aus als erwartet. Nötig sind der Zugang zum Entwicklerkonto, das aktuelle Target-API-Level, eine Liste der eingesetzten Bibliotheken und die laufenden Kosten einer App im vergangenen Jahr. Ob eine Anpassung reicht oder ein Neubau ansteht, entscheidet sich an diesen vier Angaben.
TenMedia übernimmt Wartung und Support bestehender Anwendungen auch dann, wenn andere sie gebaut haben, und beginnt mit einem Code-Audit. Aus dem Audit entsteht ein festes Stundenkontingent, in dem Updates, Store-Compliance und Weiterentwicklung zusammenlaufen. Beim Betrieb einer hochverfügbaren Plattform trägt dasselbe Modell den Dauerbetrieb. Der nächste Stichtag für App-Wartung und Support steht dabei im Kalender der Plattformen, nicht im eigenen.