App-Store-Veröffentlichung: der Weg von der fertigen App auf die Geräte

Die App-Store-Veröffentlichung ist der formale Weg zwischen fertiger Anwendung und installierbarem Eintrag im Store: Entwicklerkonto, Signatur, Eintragstexte, Angaben zum Datenschutz, Hochladen eines Builds und die Prüfung durch den Store-Betreiber. Technisch ist die Arbeit getan, organisatorisch beginnt sie hier. Jeder dieser Schritte hat einen Eigentümer.

App-Store-Veröffentlichung: was zwischen fertiger App und Store liegt

Eine mobile Anwendung wird nicht auf einen Server gelegt, sondern bei einem fremden Betreiber eingereicht. Damit ändert sich die Art der Arbeit: Nicht mehr der eigene Betrieb entscheidet, wann eine Fassung bei den Nutzern ankommt, sondern ein Regelwerk und dessen Auslegung. Wer das erst nach der Entwicklung bedenkt, hält eine fertige Anwendung in der Hand und keinen Weg zu den Geräten.

Die Kette ist auf beiden Plattformen dieselbe, die Begriffe unterscheiden sich. Ein Konto beim Betreiber begründet die Identität des Anbieters, ein Schlüssel begründet die Identität der Anwendung, ein Eintrag beschreibt sie für die Suche, ein Build trägt den Code, und eine Prüfung entscheidet über die Freigabe. Fehlt ein Glied, bleibt die Anwendung liegen.

Entwicklerkonten: wem sie gehören und warum das zählt

Beide großen Plattformen verlangen ein kostenpflichtiges Entwicklerkonto, das als Unternehmenskonto auf eine juristische Person läuft. Der Betreiber prüft dabei die Existenz des Unternehmens anhand einer Unternehmenskennung und der öffentlichen Registerdaten; ein Konto auf eine Privatperson führt dazu, dass im Store später ein Personenname statt der Firma steht.

Am Konto hängt mehr als der Zugang. Ihm gehören der Eintrag, der Name im Store, die Bewertungen, die Nutzungszahlen und die Historie der Fassungen. Ein Umzug in ein anderes Konto ist bei beiden Betreibern vorgesehen, aber ein eigenes Verfahren mit Bedingungen – und die Bewertungen einer App überstehen ihn nicht in jedem Fall. Deshalb gilt die einfache Regel: Das Konto läuft von Anfang an auf den Auftraggeber, der Entwicklungspartner arbeitet mit einer eingeladenen Rolle darin. Diese Festlegung gehört in die Leistungsbeschreibung und nicht in ein Gespräch kurz vor der Einreichung.

Signaturen, Schlüssel und der Eintrag im Store

Jeder Build wird signiert, bevor er ein Gerät erreicht. Bei Apple geschieht das über Zertifikate und Profile, die an das Konto gebunden sind; bei Android über einen Upload-Schlüssel und die Signatur des Stores selbst. Die Signatur ist die Identität der Installation: Nur eine Fassung mit demselben Schlüssel gilt für das Gerät als dieselbe Anwendung.

Daraus folgt die wichtigste Vorsichtsmaßnahme des ganzen Vorgangs: Geht der Signaturschlüssel verloren, lässt sich eine bereits installierte Anwendung nicht mehr aktualisieren. Nutzer müssten eine neue Anwendung installieren und ihre lokalen Daten verlieren. Schlüssel und Wiederherstellungsverfahren gehören darum in die Schlüsselverwaltung des Auftraggebers, nicht allein in die Bauumgebung des Entwicklungspartners.

Der Eintrag selbst ist Textarbeit mit eigenem Gewicht: Name, Untertitel, Beschreibung, Suchbegriffe, Bildschirmfotos je Geräteklasse, Kategorie, Altersfreigabe, ein erreichbarer Support-Kontakt, eine verlinkte Datenschutzerklärung und die strukturierten Angaben dazu, welche Daten die Anwendung erhebt und wofür. Diese Angaben werden mit dem Verhalten der Anwendung verglichen – Widersprüche fallen in der Prüfung auf.

Die Prüfung durch den Store und häufige Ablehnungsgründe

Geprüft wird in zwei Schichten: automatisch gegen technische Regeln – gültiger Build, erlaubte Schnittstellen, angeforderte Berechtigungen – und danach von einem Menschen, der die Anwendung auf einem Gerät benutzt. Die häufigen Ablehnungsgründe sind selten exotisch:

• Keine Zugangsdaten für die Prüfung. Hinter der Anmeldung sieht der Prüfer nichts; ohne Demozugang mit echten Inhalten endet der Vorgang sofort.
• Angaben zum Datenschutz passen nicht zum Verhalten. Die Anwendung sendet Daten, die im Formular nicht stehen, oder verweist auf eine nicht erreichbare Erklärung.
• Berechtigungen ohne erkennbaren Zweck. Standort im Hintergrund, Kontakte oder Mikrofon ohne Funktion, die sie braucht.
• Abstürze und Platzhalter. Leere Listen, tote Verweise, Texte aus der Entwicklung auf dem Prüfgerät.
• Eine Website im Rahmen. Bietet die Anwendung nichts, was die Webseite nicht auch kann, sieht der Betreiber keinen Grund für einen Store-Eintrag. Für diesen Fall ist die Progressive Web App der ehrlichere Weg.
• Bezahlung an der Abrechnung des Stores vorbei bei digitalen Inhalten, oder Nachverfolgung ohne die vom Betriebssystem vorgesehene Abfrage.

Eine Ablehnung ist kein Urteil über das Projekt: Der Betreiber nennt die Regel, auf die er sich stützt, und nach der Korrektur wird erneut eingereicht. Planbar ist dieser Abschnitt trotzdem nicht wie eigene Arbeit – er liegt bei einem Dritten. Wer den Termin einer Messe oder einer Schulung daran hängt, plant den Puffer vor der Einreichung ein und nicht danach.

Updates, Rollout und der Weg zurück

Nach der Freigabe läuft die Verteilung stufenweise: Beide Plattformen können eine neue Fassung zunächst an einen Teil der Geräte ausspielen und den Rollout anhalten, wenn die Fehlerzahlen steigen. Ein echtes Zurückrollen gibt es dagegen nicht – wer bereits aktualisiert hat, bekommt die vorherige Fassung nicht zurück. Der Weg führt über einen neuen Build mit höherer Versionsnummer.

Zwei Folgen daraus prägen den Entwurf mobiler Anwendungen. Erstens sind serverseitige Schalter wertvoll: Was sich ohne neuen Build abschalten lässt, muss nicht durch die Prüfung. Zweitens muss die Anwendung mit älteren Fassungen im Feld rechnen, denn nicht jedes Gerät aktualisiert sofort – die Schnittstelle zum Kernsystem bleibt deshalb abwärtskompatibel. Und wird ein Eintrag aus dem Store genommen, verschwindet die Anwendung nur aus Suche und Neuinstallation; auf den Geräten bleibt sie liegen, bis jemand sie löscht.

Wie wir eine App-Store-Veröffentlichung vorbereiten

Wir klären die Besitzfragen, bevor die erste Zeile Code entsteht: Entwicklerkonten laufen auf den Auftraggeber, Signaturschlüssel liegen in seiner Verwaltung, Repository und Zugänge ebenso. Eintragstexte, Bildschirmfotos und die Angaben zum Datenschutz stehen als Liefergegenstände in der Beschreibung, damit sie am Ende nicht fehlen; die erste Einreichung begleitet unsere Projektleitung. Mit vollständiger Bezahlung gehen die Nutzungsrechte am eigens erstellten Code auf den Auftraggeber über. Wie der mobile Kanal an das bestehende System angebunden wird, steht auf der Seite App-Entwicklung als zweiter Kanal zur Fachanwendung.