App-Wartung nach dem Launch: wo die eigentlichen Kosten entstehen

Wer eine App entwickeln lässt, kalkuliert das Entwicklungsbudget. Was selten kalkuliert wird, ist der Betrieb. In der Praxis entfällt über eine typische Lebensdauer von fünf Jahren ein erheblicher Teil der Gesamtkosten auf die Zeit nach dem Launch. Dieser Anteil ist kein Zeichen schlechter Entwicklung — er ist die unvermeidliche Folge davon, dass zwei Plattformbetreiber im Jahresrhythmus die Spielregeln ändern.

Der externe Änderungsdruck

Eine Website können Sie unverändert lassen, und sie funktioniert im Wesentlichen weiter. Eine App nicht. Apple und Google veröffentlichen jährlich neue Betriebssystemversionen, heben Mindestanforderungen an das verwendete SDK an, ändern Datenschutzangaben im Store, verschärfen Berechtigungskonzepte und schalten ältere Schnittstellen ab. Wer nicht mitzieht, wird zunächst gewarnt und dann aus dem Store entfernt.

Hinzu kommt die Geräte- und Versionsvielfalt. Ihre Anwendung läuft nicht auf einem System, sondern gleichzeitig auf mehreren Betriebssystemgenerationen, unterschiedlichen Bildschirmformaten und Herstellervarianten mit eigenen Anpassungen. Jede dieser Kombinationen kann Fehler zeigen, die auf dem Entwicklungsgerät nie aufgetreten sind.

Die wiederkehrenden Kostenblöcke

Der Posten mit dem schlechtesten Verhältnis von Aufwand zu Risiko sind die Zertifikate. Der Aufwand beträgt wenige Stunden im Jahr. Läuft ein Verteilungszertifikat jedoch unbemerkt ab, ist kein Release mehr möglich — und das fällt typischerweise genau dann auf, wenn ein dringender Fehler behoben werden muss.

Absturzrate richtig lesen

Die absolute Zahl der Abstürze sagt wenig aus. Aussagekräftig ist die Rate im Verhältnis zu den Sitzungen, aufgeschlüsselt nach App-Version, Betriebssystemversion und Gerätemodell. Erst diese Aufschlüsselung zeigt, ob ein Problem alle Nutzer betrifft oder eine bestimmte Konstellation — etwa eine ältere Android-Version auf Geräten eines bestimmten Herstellers.

Als Orientierung gilt: Eine absturzfreie Sitzungsrate unter 99 Prozent ist behandlungsbedürftig, unter 98 Prozent dringend. Ebenso wichtig ist die Beobachtung direkt nach einem Release. Steigt die Rate innerhalb der ersten 48 Stunden deutlich an, ist eine stufenweise Ausrollung der beste Schutz — beide Stores erlauben, ein Release zunächst nur an einen Prozentsatz der Nutzer auszuliefern.

Der teure Sonderfall: Schnittstellenbruch

Bei Websites erreichen Änderungen alle Nutzer sofort. Bei Apps nicht: Auf den Geräten Ihrer Kunden laufen alte und neue Versionen parallel, teils über Jahre. Wird eine Backend-Schnittstelle verändert, ohne die vorherige Fassung weiter zu bedienen, brechen ältere Installationen ab. Sichtbar wird das als plötzlich steigende Absturzrate und als Welle schlechter Bewertungen im Store, die sich nur langsam wieder auflöst.

Die Lösung ist Schnittstellen-Versionierung mit Übergangsfrist. Die alte Fassung bleibt aktiv, bis der Anteil der Nutzer auf alten Versionen unter eine vereinbarte Schwelle fällt. Das kostet etwas Betriebsaufwand und verhindert einen Reputationsschaden, der ungleich teurer ist.

Was Sie im Entwicklungsvertrag regeln sollten

Klären Sie vor dem Launch, wem die Store-Konten gehören — sie sollten grundsätzlich auf Ihr Unternehmen laufen und nicht auf den Dienstleister. Vereinbaren Sie außerdem die Übergabe des vollständigen Quellcodes, der Signaturschlüssel und einer Bauanleitung, mit der ein Dritter die Anwendung reproduzierbar erzeugen kann. Fehlt einer dieser Punkte, ist ein Dienstleisterwechsel später teuer oder faktisch unmöglich.

Wie wir den laufenden Betrieb organisieren, ist unter App Maintenance und Release-Support beschrieben. Läuft parallel eine Website auf derselben Datenbasis, empfiehlt sich die gemeinsame Betreuung mit der Website-Wartung, damit Release-Fenster abgestimmt sind.