App-Store-Eintrag veröffentlichen ohne fastlane

fastlane ist nicht ohne Grund die Standardantwort. Es ist ein kostenloses, MIT-lizenziertes Toolkit, und die Aktion deliver (auch upload_to_app_store) lädt Screenshots, App-Preview-Videos, Metadaten und die Binary mit einem einzigen Befehl zu App Store Connect hoch. Auf der Android-Seite macht supply (auch upload_to_play_store) dasselbe für Google Play – Metadaten, Screenshots und die APK oder das App Bundle. Führst du eines davon aus der CI heraus aus, regeneriert sich dein Eintrag bei jedem Release und driftet nie von der App ab.

Die ehrliche Frage lautet also nicht „ist fastlane gut“ – das ist es. Die Frage ist, ob du die Pipeline betreiben willst, die es gut macht, oder ob du einen Eintrag lieber ohne Pipeline aktualisierst.

Was deliver und supply wirklich tun

Beide sind Wrapper um die offiziellen Store-APIs. Im Hintergrund ruft fastlane dieselben Endpunkte auf, die du auch selbst aufrufen könntest.

• deliver (iOS). Lädt App-Name, Beschreibung, Keywords, Release-Notes, URLs, Kategorien und Review-Informationen hoch, dazu lokalisierte Screenshots und Preview-Videos. Die Binary geht über Apples iTMSTransporter hoch; die Metadaten laufen über die App Store Connect API. Es kann nach dem Upload auch direkt zur Prüfung einreichen.
• supply (Android). Lädt Metadaten, Screenshots und die APK oder AAB zu Google Play hoch, wählt einen Track und befördert Builds. Achtung, scharfe Kante: Hochgeladene Screenshots ersetzen die bestehenden für eine Sprache, statt sie zu ergänzen.

Beide authentifizieren sich mit API-Keys – ein App Store Connect API-Key für Apple, ein Service-Account-JSON für Google –, sodass sie einmal eingerichtet unbeaufsichtigt in der CI laufen. Genau das ist der ganze Reiz: Metadaten und Screenshots als Code, versioniert im Repo, bei jedem Build ausgeliefert.

Die wahren Kosten von fastlane

fastlane ist kostenlos zu installieren und kostenlos im Betrieb. Der Preis liegt in Einrichtung und Pflege – bezahlt in Engineering-Zeit.

• Eine Laufzeitumgebung zum Pflegen. fastlane ist ein Ruby-Toolchain (Ruby 3.0+), meist mit Bundler verwaltet. iOS-Arbeit braucht Xcode auf einem Mac; Android braucht die Gradle-Seite. Das ist echte Maschinerie, die installiert und gepatcht gehalten werden muss.
• Config-Dateien zum Schreiben. Ein Fastfile definiert deine Lanes; ein Deliverfile oder der Android-Metadaten-Ordner enthält die Eintragsdetails. Die erste funktionierende Version hinzubekommen dauert typischerweise ein bis zwei Tage.
• CI zum Aufsetzen. Die Automatisierung zahlt sich nur innerhalb einer Pipeline aus – das bedeutet API-Keys, Signing-Secrets und einen Build-Runner, der eingerichtet und grün gehalten wird.
• Screenshot-Aufnahme-Pflege, falls genutzt. fastlanes snapshot steuert UI-Tests im Simulator, um Screenshots pro Sprache aufzunehmen. Diese Tests sind zerbrechlich: Häufig berichtet, dass ein Setup ein paar Monate gut läuft, bis eine UI-Änderung den Ablauf bricht und der Testcode neu auf die geänderten Zustände ausgerichtet werden muss. snapshot wiederholt fehlgeschlagene Durchläufe standardmäßig – das überdeckt netzwerk- und datenbedingten Nichtdeterminismus, statt ihn zu beheben. Und die Rohausgabe hat keine Untertitel oder Hintergründe – Teams schließen das Design oft ohnehin in einem separaten Tool ab.

Das ist keine Kritik am Tool. Es ist der ehrliche Deal: fastlane verwandelt eine wiederkehrende manuelle Aufgabe in Code, und im Gegenzug pflegst du Code. Für ein Team, das wöchentlich released und einen Engineer hat, der die Release-Automatisierung verantwortet, ist das ein guter Deal. Für einen Solo-Maker oder eine PM, die einen Eintrag ein paar Mal im Jahr aktualisiert, kann die Pipeline mehr kosten, als sie einspart.

Einen Eintrag ohne fastlane aktualisieren

Verzichtest du auf fastlane, hast du immer noch drei Wege, Metadaten und Screenshots in die Stores zu bekommen.

1. Die Web-Konsolen der Stores

Der einfachste Weg. In App Store Connect bearbeitest du jede Lokalisierung von Hand und legst Screenshots in die Slots für die jeweilige Displaygröße; in der Google Play Console bearbeitest du den Store-Eintrag pro Sprache und lädst Screenshots dort hoch. Kein Code, keine Keys, nichts zu pflegen – du klickst dich durch. Der Nachteil: Es ist vollständig manuell, und über viele Sprachen hinweg Bildschirm für Bildschirm zu arbeiten ist langsam und fehleranfällig. Für eine oder zwei Sprachen völlig okay; bei 20 mühsam.

2. Die Store-APIs, direkt

Beide Stores stellen dieselben APIs bereit, die fastlane aufruft, du kannst also dagegen skripten, ohne fastlanes Ruby-Stack zu übernehmen. Apples App Store Connect API ist eine REST-API, authentifiziert mit einem kurzlebigen JWT (ES256, signiert mit deinem Key), mit Endpunkten, um Screenshot-Sets anzulegen, Bild-Bytes zu reservieren und hochzuladen sowie Metadaten zu patchen. Googles Play Developer API nutzt ein „Edits“-Modell – du öffnest einen Edit, änderst Einträge und Bilder und committest ihn dann. Das gibt dir volle Kontrolle und passt zu einem eigenen internen Dashboard, aber du schreibst und pflegst diese Integration jetzt selbst. Das ist ein kleineres Investment als eine volle fastlane-Pipeline, aber kein triviales.

3. Ein verwaltetes Tool, das den Eintrag entwirft

Der andere No-Code-Weg ist ein Tool, das dir den Eintrag erstellt, sodass nur noch bleibt, ihn in den Store zu bekommen. Hier kehrt sich der Trade-off um: Statt dass ein Engineer eine Pipeline betreibt, betreut eine PM oder ein Designer den Eintrag direkt im Browser. Du tauschst CI-Automatisierung gegen den Verzicht auf einen Engineer überhaupt.

Wo Mokbi hineinpasst – ehrlich gesagt

Mokbi versucht nicht, fastlanes CI-Geschichte zu ersetzen. Wenn dein Ziel Screenshots sind, die sich bei jedem Build ohne Menschen im Loop regenerieren, ist eine fastlane-Pipeline das richtige Werkzeug – und sie ist kostenlos. Wir sind für den anderen Fall da: für die Person, die einen polierten Eintrag veröffentlichen will, ohne Ruby, Xcode, ein Fastfile oder einen UI-Test anzufassen.

Im Browser gestaltest du die Screenshots, entwirfst den Store-Text und übersetzt den gesamten Eintrag in 50 Sprachen – kein Simulator, keine CI, kein Code. Ein Designer oder eine PM kann die gesamte Marketing-Oberfläche allein, von Anfang bis Ende, verantworten.

Hier ist die letzte Meile, und die deckt Mokbi ab. Es gestaltet die Screenshots und die Feature-Grafik, schreibt und übersetzt den gesamten Eintrag in 50 Sprachen und überträgt das Ergebnis dann direkt über die Play Developer API zu Google Play und bereitet die App-Store-Version in App Store Connect vor, bereit für deinen Klick auf Submit – dieses abschließende Submit samt Prüfung verlangt Apple selbst, eine Apple-Regel, keine Lücke bei uns. Dieselben Endpunkte, die fastlane aufruft, nur ohne die Pipeline.

Was du wann wählst

• Wöchentlich releasen, ein Engineer an Bord, null Drift gewünscht? fastlane. Es ist kostenlos, automatisiert und hält Screenshots und Metadaten im Gleichschritt mit der App. Nichts hier schlägt das.
• Einen Eintrag ein paar Mal im Jahr aktualisieren, keine CI übrig? Die Web-Konsole, oder ein Tool, das den Eintrag entwirft. Die Pflege der Pipeline lohnt sich bei diesem Tempo nicht.
• Programmatische Kontrolle nötig, aber nicht fastlanes Stack? Ruf die App Store Connect API und die Play Developer API direkt auf.
• Ein Designer oder eine PM soll den Eintrag über viele Sprachen hinweg verantworten? Entwerfen, übersetzen und veröffentlichen aus dem Browser – Mokbi überträgt zu Google Play und bereitet die App-Store-Version zum Einreichen vor.

fastlane verdient sich seinen Platz als kostenloser, automatisierter Platzhirsch. Der No-Code-Weg ist nicht „besser“ – er ist ein anderer Deal: Du gibst die CI-Automatisierung auf, und dafür muss niemand eine Pipeline bauen oder pflegen, nur um einen Eintrag zu aktualisieren.

Was du als Nächstes lesen solltest

• Die besten Tools zum Veröffentlichen von App-Store-Einträgen
• Screenshots mit der App Store Connect API hochladen
• Im Vergleich: Mokbi vs. fastlane

Editor öffnen →