Nach dem App-Launch: Wartung und Versionsverwaltung
Launch ist nicht die Ziellinie. So halten Betriebssystem-Updates, Store-Versionsregeln und ein Wartungskalender eine mobile App am Leben.
rabbitclip-TeamVeröffentlicht: 4 Min. Lesezeit
Kurz gesagt
Eine mobile App braucht nach dem Launch ein paar Mal im Jahr ein Update; Betriebssysteme, Store-Regeln und Bibliotheken ändern sich alle, und eine unbetreute App hört irgendwann auf, richtig zu funktionieren, oder wird aus dem Store genommen.
Hier unterscheidet sie sich von einer Website. Eine Webseite, die für eine neue Browserversion aktualisiert wird, öffnet meist weiterhin problemlos; eine mobile App kann bei einem Betriebssystem-Update aus dem Takt geraten, und eine unbetreute Version kann aus dem Store fallen, sobald eine neue Mindestregel greift.
Was Wartung tatsächlich bedeutet
Wartung bedeutet, die Bibliotheken der App, die Betriebssystem-Kompatibilität und die Einhaltung der Store-Richtlinien aktuell zu halten; das ist eine eigene Aufgabe neben neuen Features, die nach einem regelmäßigen, planbaren Kalender läuft.
Eine App ist kein Produkt, das man einmal schreibt und liegen lässt; wie jede lebende Software muss sie sich verändern, während sich ihr Umfeld verändert.
Die Unterscheidung lohnt sich klar zu benennen: Wartung hält die App so aufrecht, wie sie ist; neue Feature-Arbeit lässt sie wachsen. Dasselbe Team kann beides tun, aber sie brauchen getrennte Budgetposten, sonst verliert Wartung jedes Mal leise gegen Wachstumsarbeit.
Warum Betriebssystem-Updates Druck erzeugen
Apple und Google veröffentlichen jeweils eine große Betriebssystemversion pro Jahr; mit jedem Release werden manche APIs veraltet erklärt und manche Berechtigungsverhalten ändern sich. Code, der im Vorjahr einwandfrei lief, kann sich auf der neuen Version unerwartet verhalten.
Deshalb muss die App bei jedem großen Betriebssystem-Release erneut getestet werden; wird dieser Test hinausgezögert, zeigt sich das meist an Nutzerbeschwerden.
Eine Berechtigungsabfrage, die zuvor ein Bildschirm war, kann sich in einem neuen Release beispielsweise in zwei Schritte aufteilen; der Code läuft weiter, aber der Nutzer sieht nie den erwarteten Bildschirm. Solche Änderungen zeigen sich nur bei echten Tests, nicht bei einer Code-Prüfung.
Zwingende Updates auf Store-Seite
Google Play hebt sein minimales Ziel-API-Level jedes Jahr an; Apps, die darunter bleiben, verlieren die Fähigkeit, neu installiert oder aktualisiert zu werden. Das heißt, die App kann faktisch aus dem Store verschwinden, selbst wenn der Code selbst nicht kaputt ist.
Auf Apples Seite werden ähnlich Apps, die mit einem alten SDK kompiliert wurden, irgendwann nicht mehr zur Einreichung akzeptiert; deshalb gehört ein jährlicher Rebuild- und Testzyklus zur Aufgabe.
Wie man einen Wartungskalender aufsetzt
In der Praxis funktioniert es, zwei oder drei feste Wartungsfenster pro Jahr festzulegen: Bibliotheks-Updates, Tests neuer Betriebssysteme, Store-Richtlinienprüfungen. Außerhalb dieser Fenster löst nur ein wirklich kritischer Fehler dringende Arbeit aus.
- Kompatibilitätstests bei einer neuen Betriebssystemversion
- Ein Rebuild, wenn sich die Store-Anforderung an Ziel-API/SDK ändert
- Sicherheitsupdates für verwendete Drittanbieter-Bibliotheken
- Regelmäßige Durchsicht von Nutzerfeedback und Absturzberichten
Was ohne Wartung passiert
Im mildesten Fall wird die App langsam träge oder wirft auf manchen Bildschirmen Fehler. Im schlimmsten Fall sperrt der Store sie für neue Nutzer oder entfernt sie ganz, sobald das Ziel-API-Level zu weit veraltet. Beides braucht Zeit, um es umzukehren.
Die Händler-App einer Möbelwerkstatt, zwei Jahre lang unangetastet, verlor die Fähigkeit zur Neuinstallation, als Google Play sein Ziel-API-Level anhob; Händler, die das Telefon wechselten, konnten sie nicht mehr installieren. Die eigentliche Behebung dauerte eine Woche, aber das Problem zu bemerken dauerte fast sechs Monate, weil niemand regelmäßig nachsah.
Wer sollte die Wartung übernehmen: intern oder eine Agentur
In einem kleinen Unternehmen klingt es einfach, einer Person zu sagen 'kümmere dich doch auch um die App', aber die Wartung wird am Ende zwischen dem eigentlichen Job dieser Person eingequetscht und jedes Mal aufgeschoben. So hört Wartung am häufigsten leise auf zu passieren.
Der Entscheidungstest ist folgender: Ist die jährliche Wartungslast der App (Testen, Rebuild, Store-Prüfungen) klein genug, um die regelmäßige, wiederholbare Aufgabe einer Person zu sein, oder braucht sie ein eigenes Budget und einen eigenen Kalender. Trifft Letzteres zu, verhindert es, die Wartung an ein externes Team unter einer festen Vereinbarung zu geben, dass die Arbeit in den Lücken verloren geht.
Häufige Fehler
Der häufigste Fehler ist, Wartung nach dem Motto 'wir kümmern uns darum, wenn etwas kaputtgeht' zu behandeln; Store-Anforderungen kommen leise, ohne erst ein offensichtliches Problem zu zeigen, und die App kann aus dem Store fallen, bevor es jemand bemerkt. Wartung sollte geplant, nicht reaktiv sein.
Der zweite Fehler ist, eine neue Betriebssystemversion erst beim offiziellen Release zu testen; das Testen ab dem Moment der Beta gibt Zeit, Probleme zu finden und zu beheben, bevor die öffentliche Version erscheint.
- Sich an Wartung erst erinnern, wenn etwas kaputtgeht
- Ein neues Betriebssystem nur bei der offiziellen Version testen
- Wartung einer einzigen Person überlassen, ohne festen Kalender
Der Launch ist kein Ende, sondern der Beginn eines regelmäßigen Wartungszyklus, und dieser Zyklus läuft ohne Überraschungen, sobald ein fester Kalender dahintersteht. Hat Ihre App noch keinen Wartungskalender, lohnt es sich, das gemeinsam aufzusetzen.
Häufige Fragen
Was passiert, wenn eine App nie aktualisiert wird?
Sie kann eine Weile problemlos laufen, gerät aber aus dem Takt, sobald sich das Betriebssystem oder eine Store-Regel ändert, und kann irgendwann für neue Installationen gesperrt werden.
Wie viele Updates pro Jahr reichen für die Wartung?
Meist zwei oder drei geplante Updates; ein ernster Fehler erhält außerhalb davon eine dringende Korrektur.
Sollte die App sofort beim Erscheinen eines neuen Betriebssystems getestet werden?
Das Testen gegen die Beta-Version, bevor die öffentliche Version erscheint, fängt Probleme früh ab, statt erst nachdem Nutzer sie melden.
Ist eine App ohne Wartungsvereinbarung gefährdet?
Mit der Zeit ja; verfolgt niemand das, können Store-Anforderungen oder Betriebssystem-Änderungen unbemerkt bleiben, bis die App betroffen ist.
