Zurück

Wird Ihre App in drei Jahren noch funktionieren?

on 

Den Launch zeigt Ihnen jeder. Die drei Jahre danach zeigt Ihnen niemand. Hier steht, was sich in dieser Zeit rund um eine App bewegt, was die Plattform an Ihrer Stelle abfängt und was auf Ihren Namen bleibt.

Tag 1.095was in den drei Jahren nach dem Launch mit einer App passiert.

Ihre App ist veröffentlicht. Und jetzt?

Am Launch-Tag ist alles gut: Sie haben Ihre App laufen sehen. Sie ist in den Stores, die ersten Nutzer laden sie herunter, alles reagiert. Die Frage, auf die es wirklich ankommt, stellt sich an diesem Tag nicht.

Sie stellt sich viel später — an dem Morgen, an dem Ihnen jemand schreibt, dass etwas nicht mehr funktioniert. Dazwischen sind drei Jahre vergangen, in denen Sie nichts angerührt haben.

Ihre App hat sich um kein Komma verändert. Die Welt um sie herum schon. Genau darin liegt das Paradox: Eine App kann aufhören zu funktionieren, ohne dass sich in ihr eine einzige Zeile bewegt hätte.

Was sich um sie herum bewegt

Im Wesentlichen vier Bewegungen. Die Stores verschärfen ihre Regeln: Datenschutzangaben, Mindestversionen, überarbeitete Berechtigungsrichtlinien. Die Betriebssysteme lassen unterwegs Funktionen fallen und machen andere nach und nach zur Pflicht. Manche Dinge haben ein Ablaufdatum: Zertifikate und manche Dienstzugänge laufen aus — das SSL-Zertifikat einer Domain zum Beispiel. Und die Daten häufen sich, bis das, was einmal sofort da war, träge wird.

Pierre-Laurent hat die ausführliche Bestandsaufnahme dessen, was still verfällt, samt Store-Richtlinien und Fristen geschrieben. Ich werde das hier nicht wiederholen. Was mich in diesem Artikel interessiert, ist die Frage danach: Wenn man das alles weiß — wer kümmert sich darum?

Einmal behoben, beim nächsten Build geerbt

Zu sagen, eine Plattform «kümmere sich um die Wartung», ist so vage, dass es hohl wird. Der eigentliche Mechanismus passt in einen Satz: Das Problem wird einmal behoben, auf Plattformebene, und jede App erbt die Korrektur bei ihrem nächsten Build.

Wenn eine neue Datenschutzanforderung in Kraft tritt, sind es nicht Tausende App-Ersteller, die jeder für sich Apples Dokumentation lesen. Es ist ein Team, einmal, das die Engine aktualisiert, die die Apps baut. Wenn ein System eine Funktion fallen lässt, wird die betroffene Komponente einmal neu geschrieben, an derselben Stelle. Sie haben nichts gelesen, nichts migriert, nichts entschieden.

Es lohnt sich, die Alternative auszusprechen, denn sie ist das ganze Argument dafür, auf einer Plattform zu bauen statt eigenen Code zu pflegen. Wenn Sie den Quellcode der App selbst pflegen müssen — geschrieben von einer Entwicklerin, die Sie eingestellt haben, oder an einem Nachmittag aus einem Prompt erzeugt —, dann beschreibt derselbe Satz Ihren Nachmittag. Sie müssen bemerken, dass sich die Regel geändert hat, verstehen, was sie verlangt, den Code ändern, neu bauen, erneut einreichen. Niemand hat es einmal für alle getan: Es wird einmal für Sie getan, und dann wieder für die nächste Änderung, und für die übernächste. Eine App zu produzieren ist bemerkenswert günstig geworden, und das ist wirklich eine gute Nachricht. Sie aktuell zu halten hat sich keinen Millimeter bewegt. Pierre-Laurent hat diese Lücke im Detail beschrieben.

Ein Punkt der Ehrlichkeit, weil er zählt: Diese Beobachtung erfasst nur, was jemand hat kommen sehen. Die Regeln zu lesen, bevor sie gelten, eine Komponente neu zu schreiben, bevor ein Wegfall zum Ausfall wird — das ist ein Handwerk, das laufend ausgeübt wird, keine automatische Garantie.

Der Fall, über den nie gesprochen wird: die App, die man schlafen ließ

Alles bisher Gesagte gilt für eine lebendige App, die hin und wieder neu veröffentlicht wird. Aber die eigentliche Sorge liegt woanders, und niemand formuliert sie: Ich habe meine App zwei Jahre liegen lassen. Ist sie verloren?

Nein. Und der Grund liegt darin, wie sich die Arbeit ansammelt: Die Korrekturen warten auf Ihre App, sie laufen ihr nicht hinterher. Eine App, die niemand anfasst, repariert sich nicht über Nacht von selbst — während sie schläft, kommt nichts bei ihr an. Aber in diesen zwei Jahren wurde jede Regeländerung und jede von iOS oder Android fallen gelassene Funktion einmal bearbeitet, vorgelagert, für alle Apps der Plattform. Diese Arbeit ist nicht verdunstet, weil Ihre still war. Sie liegt da, gestapelt, und wartet.

Die Folge ist sehr konkret: Wenn Sie zurückkommen, holen Sie nicht zwei Jahre von Hand auf. Sie bauen neu, und Ihre App kommt auf dem Stand der heutigen Welt heraus, nicht auf dem der Welt, in der sie entstanden ist. Aufholen ist kein Projekt, sondern ein Build. Sie müssen nicht wissen, was darin steckte.

Genau das passiert nicht, wenn Sie den Quellcode selbst pflegen. Während sie schlief, hat sich nichts für Sie angesammelt. Zwei Jahre Änderungen bleiben zwei Jahre Änderungen und warten darauf, dass jemand — Sie oder jemand, den Sie bezahlen — sie eine nach der anderen abarbeitet, bevor die App wieder hinausgehen kann.

Was uns gehört, was bei Ihnen bleibt

Das ist die eigentliche Antwort auf die Frage im Titel, und sie passt in zwei Spalten.

Auf unserer Seite: die Engine, die die Apps baut, dauerhaft auf aktuellem Stand gehalten. Das Lesen der Store-Regeln, bevor sie greifen. Das Neuschreiben von Komponenten, bevor ein Wegfall zum Ausfall wird. Die Kette, die Ihre Benachrichtigungen ausliefert. Das SSL-Zertifikat Ihrer Domain, vor jedem Stichtag erneuert. Nichts davon verlangt von Ihnen eine Entscheidung — nicht einmal, davon zu wissen.

Auf Ihrer Seite, und niemand kann es an Ihrer Stelle tun:

  • Ihre Apple- und Google-Entwicklerkonten. Sie laufen auf Ihren Namen — das ist es, was die App zu Ihrer macht — und sie müssen erneuert werden. Ein abgelaufenes Konto nimmt die App aus den Stores, so gut der Inhalt auch sein mag.
  • Die Angaben, die Ihre Inhalte und Ihren Umgang mit Daten beschreiben. Sie handeln von Ihrem Geschäft, nicht von unserem: Wir können sie aus den Funktionen vorbereiten, die Sie tatsächlich aktiviert haben, aber nicht an Ihrer Stelle entscheiden, was Sie mit den Daten Ihrer Nutzer tun.
  • Der Schritt, das Update abzuschicken. Jede neue Version durchläuft die Store-Prüfung: Die Plattform bereitet alles vor, Sie lösen aus. Wenn genau das lästig ist, gibt es GoodBarber Takes Care — dort reichen wir die Updates an Ihrer Stelle bei den Stores ein.

Die Liste ist kurz. Das ist Absicht — und jede dieser Zeilen verdient einen eigenen Artikel. Genau das wird diese Serie tun.

Was Ihnen das an Freiraum lässt

Der eigentliche Nutzen ist nicht technisch, sondern Zeit. Die Stunden, die Sie nicht damit verbringen, Apples Release Notes zu lesen, zu entschlüsseln, was eine Datenschutzangabe ist, oder zu suchen, warum ein Zertifikat abgelaufen ist, verbringen Sie mit Ihren Inhalten, Ihrem Publikum, Ihrem Geschäft.

Es ist ein Nutzen, der sich schwer bewerben lässt, weil man ihn nicht sieht: Wenn er wirkt, passiert nichts. Keine Demo kann ihn beweisen; nur die Zeit bestätigt ihn. Das ist es, was die Plattform seit 2011 unauffällig tut.

Wenn Sie das technische Detail interessiert: Ich habe an anderer Stelle aus Sicht der Technik beschrieben, was in drei Jahren wirklich kaputtgeht.

Anfangen

Am einfachsten sehen Sie, wie eine auf dieser Mechanik gebaute App aussieht, wenn Sie Ihre eigene beginnen: meine App mit GoodBarber erstellen.

Häufige Fragen

Wird meine App in drei Jahren noch funktionieren?

Eine App, die man strikt unangetastet lässt, fällt irgendwann hinter ihre Umgebung zurück — das gilt überall. Der Unterschied liegt darin, was das Aufholen kostet: Auf einer Plattform, die die Änderungen abfängt, sind die Korrekturen bereits gemacht und warten auf Ihre App. Sie auf den aktuellen Stand zu bringen ist ein Neubau, kein Projekt.

Ich habe meine App zwei Jahre liegen lassen. Ist sie verloren?

Nein. Während sie schläft, kommt nichts bei einer App an, aber die gesamte in der Zwischenzeit auf Plattformebene geleistete Arbeit wartet auf sie: Beim nächsten Build kommt sie auf aktuellem Stand heraus. Genau darin liegt der Unterschied zu einer App, deren Quellcode Sie selbst pflegen müssen, wo sich nichts für Sie angesammelt hat.

Wer ist wofür zuständig — die Plattform oder ich?

Die Plattform übernimmt, was allen Apps gemeinsam ist: die Engine, die sie baut, die Einhaltung der Store-Regeln, den Ersatz weggefallener Komponenten und die Benachrichtigungs-Infrastruktur. Bei Ihnen bleiben Ihre Apple- und Google-Entwicklerkonten, die Angaben zu Ihren Inhalten und die Entscheidung, Updates zu veröffentlichen.

Braucht man technische Kenntnisse, um eine App langfristig am Leben zu halten?

Nein, und genau das ist der Punkt: Der Teil, der sie verlangt, wird einmal vorgelagert für alle Apps erledigt. Was auf Ihrer Seite bleibt, ist administrativ und redaktionell — Konten erneuern, Ihre Inhalte beschreiben, den Zeitpunkt der Veröffentlichung wählen — kein Code.

Warum ist meine App langsamer als beim Launch?

Meistens ist nichts kaputt: Das Volumen hat sich verändert. Was bei einem kleinen Katalog sofort da war, kostet mehr Arbeit, wenn er über Jahre gewachsen ist. Es ist die einzige der vier Bewegungen, die aus Ihrem eigenen Erfolg kommt und nicht von außen — und das Thema eines kommenden Artikels dieser Serie.