Der Launch-Tag wird als Ziellinie behandelt, aus gutem Grund — er ist der sichtbare Meilenstein, das, was gefeiert und berichtet wird. Für eine App ist er eher die Startlinie einer anderen, laufenden Verpflichtung, denn anders als eine Website, die größtenteils stillsteht, bis sie jemand bewusst ändert, lebt eine App innerhalb zweier Betriebssysteme und zweier App-Stores, die sich weiter verändern, ob das Unternehmen das will oder nicht.
Betriebssystem-Updates muss man zwangsläufig mitverfolgen
Beide großen mobilen Plattformen veröffentlichen jährliche Updates, und jedes kann das Verhalten bestehenden Codes verändern — eine Berechtigung, die früher automatisch erteilt wurde, braucht jetzt eine explizite Abfrage, eine API, von der die App abhängt, wird mit Countdown bis zur Entfernung als veraltet markiert, eine Bildschirmgröße oder ein Interaktionsmuster, das die Oberfläche voraussetzte, gilt auf neuen Geräten nicht mehr. Eine App, die nicht aktiv gepflegt wird, bricht nicht zwangsläufig am Tag zusammen, an dem eine neue OS-Version erscheint, aber sie sammelt mit jedem Release kleine Risse an, und wenn irgendwann sichtbar etwas kaputtgeht, liegt das meist daran, dass sich über mehrere Update-Zyklen kleine, unbehandelte Änderungen angehäuft haben.
Store-Richtlinienänderungen kommen ohne Vorwarnung und mit Frist
Die Review-Richtlinien der App-Stores ändern sich nach ihrem eigenen Zeitplan, nicht dem des Unternehmens, und eine Richtlinienänderung kann verlangen, wie die App eine Berechtigung anfragt, ein Abonnement präsentiert oder einen bestimmten Datentyp behandelt — mit einer angehängten Compliance-Frist, nach der die App vollständig aus dem Store entfernt werden kann, bis sie korrigiert ist. Das ist keine hypothetische Risikokategorie; es ist ein routinemäßiger Teil des Betriebs in einem App-Store, und eine App, die niemand auf solche Änderungen hin beobachtet, erfährt erst davon, wenn sie bereits entfernt oder markiert wurde — eine weit störendere Art, von einem Richtlinien-Update zu erfahren, als vorab ein Änderungsprotokoll zu lesen.
Der Supportaufwand hört mit dem Launch nicht auf
Jedes echte Update der zugrunde liegenden Plattform, jede neue Gerätegröße, jeder Grenzfall, den ein echter Nutzer findet und den Tests nicht abdeckten, erzeugt eine Support-Anfrage oder einen Fehlerbericht, und das Volumen sinkt nach dem Launch nicht so, wie ein Projektzeitplan es nahelegt — es verschiebt sich von „die erste Version richtig hinbekommen" zu „ein lebendes Produkt für Menschen am Laufen halten, die jetzt davon abhängen", was eine andere, fortlaufende Art von Arbeit ist, keine kleinere Version desselben endlichen Projekts.
Was ein Wartungsplan tatsächlich abdecken muss
Ein realistischer Plan sieht periodisches Testen gegen neue OS-Releases vor, bevor sie verpflichtend werden, nicht nachdem etwas kaputtgeht; einen ständigen Prozess zur Verfolgung von Store-Richtlinienänderungen, statt sie über eine Ablehnungsmeldung zu entdecken; und einen tatsächlich personell besetzten Support-Kanal, kein Formular, das still ungelesene Nachrichten anhäuft. Nichts davon muss groß sein — eine kleine, regelmäßige Zeitzuteilung reicht meist aus —, aber es muss als definierte, laufende Verpflichtung existieren, nicht als Annahme, dass eine fertige App fertig bleibt.
Warum das vor dem Launch zählt, nicht danach
Die realistischen Kosten, eine App am Leben zu halten, lohnt es sich zu verstehen, bevor die erste Version ausgeliefert wird, nicht erst, wenn der erste Support-Rückstau oder die erste Store-Ablehnung sie unumgänglich machen — eine App, die als einmaliges Projekt budgetiert wird, ohne eingeplante laufende Zuteilung, ist eine App, die entweder still verfällt oder später eine ungeplante, größere Korrektur erfordert, beides teurer, als eine geplante Wartung gekostet hätte.
Das gehört zu den anderen Bauen-oder-Kaufen-Fragen aus wie man Software baut, die zum Unternehmen passt — eine App ist ebenso wenig eine einmalige Lieferung wie eine eingestellte Mitarbeiterin eine einmalige Einstellung ist. Unser Mobile-Team plant die Wartungsverpflichtung zusammen mit dem Bau, nicht als nachträglichen Gedanken, sobald die App bereits live ist.
