So arbeitet der Submission-Agent: vom Repository bis zur Store-Prüfung

Das Ausliefern ist der Teil der App-Entwicklung, den die meisten vor sich herschieben. Der Build ist fertig, und was bleibt, ist die Bundle-ID, die Frage zur Exportkontrolle, der Fragebogen zur Altersfreigabe, die Datenschutzseite, die du nicht hast, die Screenshot-Größen und die Build-Nummer, die höher sein muss als die letzte. Dafür gibt es den Submission-Agenten. Das hier ist, was er tatsächlich tut, Schritt für Schritt, und wo er anhält und auf dich wartet.

Die Kurzfassung: Er liest dein Repository, bereitet das Store-Listing vor, prüft das Release gegen die Dinge, wegen derer Stores Apps ablehnen, baut deinen Build oder übernimmt ihn, lädt ihn hoch und hält an. Eine erste Veröffentlichung geht nie ohne deine Freigabe in die Prüfung. Ein Update kann direkt in die Prüfung gehen, aber nur, wenn du diesen Weg gewählt und das Listing freigegeben hast.

Was du einmal verbindest

Drei Verbindungen erledigen die Arbeit, und du richtest sie einmal pro App ein.

GitHub. Uprate liest das Repository über die GitHub-API, um die App zu erkennen und zu analysieren. Es klont deinen Code nicht, zeigt deinen Quelltext nicht in seiner Oberfläche und öffnet keine Pull Requests dagegen, mit einer Ausnahme, die weiter unten erklärt wird.

Ein Store-Schlüssel zum Veröffentlichen. Für den App Store hinterlegst du in den Einstellungen einen App Store Connect API-Schlüssel, getrennt von dem Schlüssel, der Rezensionen liest. Uprate prüft ihn, indem es die Apps auflistet, die er erreichen kann, speichert ihn verschlüsselt und zeigt dir, welche Apps dieser Schlüssel veröffentlichen darf. Für Google Play verbindest du ein Service-Konto für das Paket, dieselbe Verbindung, die auch die Rezensions-Inbox nutzt. Wenn du mit Expo baust, verbindest du zusätzlich das Expo-Konto, dem das Projekt gehört.

Wer den Knopf drücken darf. In einem Team können Owner und Mitglieder eine Einreichung starten. Reviewer- und Analytics-Sitze können den Lauf öffnen und jeden Schritt lesen, aber keinen starten, einreichen oder abbrechen.

Die App hinzufügen

Du wählst ein Repository, und Uprate sucht die App darin: package.json, app.json oder app.config, die iOS-Info.plist und das Xcode-Projekt, die Android-build.gradle und das Manifest. Daraus füllt es App-Namen, iOS-Bundle-ID, Android-Paket und Expo-Projekt aus, und bei einem Monorepo fragt es, in welchem Ordner die App liegt. Alles, was es falsch erkannt hat, kannst du korrigieren, bevor die App angelegt wird.

iOS und Android sind getrennte Spuren. Apple kann freigeben, während Google nachfragt, deshalb bekommt jeder Store seinen eigenen Lauf mit eigenem Status und eigenen Aktionen, und eine App, die nur eine iOS-Bundle-ID hat, zeigt nur eine Spur. Pro Store und App ist immer nur eine Einreichung offen; läuft schon eine, führt dich der Start-Button dorthin, statt eine zweite zu beginnen.

Wo soll es anhalten

Jeder Start beginnt mit einer Frage, und die Antwort entscheidet, wie weit der Lauf von allein geht.

Plan	Was passiert	Wo es wartet
Erst testen (Standard)	Bereitet das Listing vor, führt die Prüfungen aus, baut deinen Build oder übernimmt ihn und lädt ihn zu TestFlight oder in die interne Testphase von Google Play. Nichts erreicht App Review.	Bei „Ready to submit“, bis du auf Einreichen drückst.
Live gehen	Dasselbe, dann weiter in die Store-Prüfung. Bei einer ersten Veröffentlichung gibst du vorher die vorbereiteten Store-Angaben frei; bei einem Update wird dir das Listing gezeigt, bevor es geschrieben wird.	Nach dem Build nirgends, außer eine Prüfung schlägt fehl.
Nur prüfen (App Store)	Geht jeden Schritt durch und berichtet, was ein echtes Release tun würde. Es wird nichts gebaut und bei Apple nichts verändert.	Endet mit „Check complete“.

Die zweite Frage ist, woher der Build kommt. Mit Build with Expo baut Uprate aus deinem Repository. Mit Upload IPA oder Upload AAB ziehst du einen signierten Build aus deinem eigenen Werkzeug hinein; Uprate prüft ihn, liest Version und Build-Nummer daraus und lädt den iOS-Build mit Apples Transporter hoch. Mit Use ASC build oder Use Google Play build wählst du einen Build, der in der Store-Konsole bereits verarbeitet ist, der Weg für alle, die aus Xcode oder ihrer eigenen CI hochladen.

Ein Vorbehalt bei Android: Builds aus dem Repository brauchen einen isolierten Runner, und dieser Runner ist nicht Teil des gehosteten Produkts. Android-Läufe nutzen deshalb heute ein hochgeladenes AAB oder APK, oder einen Build, der schon auf Google Play liegt.

Was die Analyse bei einer ersten Veröffentlichung erzeugt

Eine erste Veröffentlichung ist der Fall, in dem die App im Store noch nicht existiert, und dort passiert der größte Teil der Analyse. Uprate liest einen begrenzten Ausschnitt des Repositorys, app.json, package.json, die README und eine Handvoll Quelltext-Auszüge, und lässt acht Analyzer darüber laufen.

Der Listing-Text kommt zurück als Name und Untertitel innerhalb von Apples 30 Zeichen, eine Kurzbeschreibung für Google Play, eine Beschreibung unter 4.000 Zeichen, Keywords unter 100 Zeichen, Werbetext sowie die Support- und Marketing-URLs, die er gefunden hat. Kategorien und der Fragebogen zur Altersfreigabe werden aus dem beantwortet, was die App tut. Die Frage zur Exportkontrolle wird aus dem Code beantwortet, mit den Belegen, die dafür genutzt wurden. Datenschutz-Labels werden aus den Abhängigkeiten und den APIs vorgeschlagen, die der Code aufruft, wieder mit Dateipfaden und Ausschnitten als Beleg. Eine Datenschutzerklärung und Nutzungsbedingungen werden erzeugt und auf einer öffentlichen Uprate-Seite gehostet, weil der Store eine URL braucht und die meisten Erst-Apps keine haben. Zum Schluss liest ein ASO-Audit das gesamte Paket und listet Probleme als kritisch, groß, klein oder Hinweis, und es markiert Fachjargon in Texten für Endnutzer, damit „gebaut mit React Native und TypeScript“ nicht in einer Beschreibung landet.

Alles, was die Analyse erzeugt hat, ist im Lauf bearbeitbar, pro Sprache, und bleibt ein Vorschlag, bis du es freigibst.

Updates überspringen fast alles davon. Das Listing wird aus dem übernommen, was im Store live ist, die Antwort zur Exportkontrolle wird neu aus dem Code abgeleitet, weil Apple sie für jeden Build verlangt, der Datenschutz-Scan läuft trotzdem, damit du einen codebasierten Vorschlag zum Vergleich mit deinen bestehenden Labels bekommst, und der Text für „Neue Funktionen“ wird aus den Commits seit dem letzten Release entworfen.

Die Prüfungen, bevor etwas gebaut wird

Bevor ein Build startet, durchläuft der Lauf eine Checkliste gegen Store und Repository. Sie bestätigt, dass Expo-Konfiguration und eas.json vorhanden und gültig sind, dass der Expo-Owner zu deinem Konto passt, dass App-Version und Build-Nummer höher sind als das, was App Store Connect schon hat, dass die Bundle-ID in der Konfiguration zum Store passt, dass Verschlüsselungsantwort, Altersfreigabe und Hauptkategorie gesetzt sind, dass die URL der Datenschutzerklärung öffentlich ist und tatsächlich lädt, und dass die vom Store verlangten Screenshot-Größen abgedeckt sind. Jeder fehlgeschlagene Punkt ist ein Satz mit dem Feld, das zu korrigieren ist, und nach der Korrektur kannst du den Schritt erneut ausführen.

Ein zweiter Durchgang liest das Repository nach den Dingen, für die App Review Apps zurückschickt: fehlende Begründungstexte für Kamera, Fotos, Standort, Kontakte oder Mikrofon, eine fehlende Tracking-Berechtigung bei Apps, die nach Tracking aussehen, Login über Drittanbieter ohne „Mit Apple anmelden“, Konten ohne Möglichkeit, sie in der App zu löschen, Metadaten zu In-App-Käufen sowie nutzergenerierte Inhalte ohne Melde- und Moderationsfunktion.

Der dritte Durchgang ist der App-Review-Check. Er nimmt die Belege aus den beiden Durchgängen davor und die vorbereiteten Metadaten und prüft sie gegen einen handverlesenen Satz von 26 Regeln aus Apples App Review Guidelines. Das Ergebnis ist eine Liste von Befunden, jeder entweder ein Risiko oder ein Hinweis, jeder mit dem Beleg, auf dem er beruht, und der Richtlinie, zu der er gehört. Regeln, die er nicht prüfen konnte, werden als ungeprüft aufgeführt statt geraten. Dieser Check blockiert eine Einreichung nie von allein und nennt nie eine Ablehnungswahrscheinlichkeit.

Probleme, keine Punktzahlen Uprate zeigt keinen Bereitschaftsprozentsatz und keinen Risikowert. Es zeigt die Anzahl der Probleme, jedes mit Feld und Lösung. Schlägt ein Schritt fehl, erzeugt „Copy fix prompt“ einen Prompt mit Diagnose und Dateiverweisen für deinen eigenen Coding-Agenten. Uprate schreibt keinen Code in dein Repository.

In den Store schreiben, und die Pause

Sobald das Listing freigegeben ist, schreibt der Lauf es über die API des Stores: die Version, die Listing-Texte in jeder Sprache, Kategorien, Altersfreigabe und das Screenshot-Set, das du angehängt hast. Preis und Verfügbarkeit werden vor der Einreichung zur Prüfung geprüft und gesetzt. Existiert die App in App Store Connect noch nicht, werden zuerst die Bundle-ID registriert und der App-Eintrag angelegt. Eines wird nicht geschrieben: Apples Datenschutz-Labels haben keine öffentliche API, deshalb zeigt Uprate seinen Vorschlag und lässt dich bestätigen, dass du sie in App Store Connect ausgefüllt hast, bevor eine erste Veröffentlichung weitergeht. Während ein Lauf schreibt, baut oder in der Prüfung ist, ist der Listing-Editor für diese App gesperrt, damit sich beide nicht in die Quere kommen.

Mit Build with Expo auf iOS öffnet Uprate einen einzigen Pull Request in deinem Repository, der eine Workflow-Datei unter .eas/workflows/ hinzufügt. Du mergst ihn, und von da an löst Uprate diesen Workflow über Expos GitHub-App für einen bestimmten Commit aus. Der Workflow baut das Produktions-Binary und reicht es bei App Store Connect ein, über Expos Credentials-Service, sodass kein App Store Connect-Schlüssel in deinen Repository-Secrets landet. Das ist die einzige Stelle, an der Uprate dein Repository anfasst, und es ist eine Workflow-Datei, nicht dein Quelltext.

Der Build wird zu TestFlight oder in die interne Testphase hochgeladen. Im Standardplan parkt der Lauf dann bei „Ready to submit“. Du installierst den Build, probierst ihn aus und drückst auf Einreichen, wenn du zufrieden bist. Bei „Live gehen“ läuft der Lauf weiter in die Prüfung. Auf Google Play landet ein Konto, für das Googles Pflicht zum geschlossenen Test noch gilt, stattdessen bei „Live on internal testing“, und der Lauf beobachtet weiter und wechselt von allein auf freigegeben, sobald das Produktions-Release live ist.

In der Prüfung, und danach

Uprate fragt den Prüfstatus regelmäßig ab und zeigt den Lauf als eine Zeile pro Phase, mit den Details jedes Ereignisses hinter einem Umschalter. Freigegeben ist freigegeben. Eine Ablehnung wird mit Apples Statusdetails in verständliches Englisch übersetzt angezeigt, plus einem Verweis auf „Review Issues & Messages“ in App Store Connect, weil die vollständige Nachricht zur Richtlinie nicht über die API verfügbar ist. Korrigiere App oder Listing und drücke auf erneut einreichen, mit einer Notiz, wenn du festhalten willst, was sich geändert hat.

Ein fehlgeschlagener Schritt ist kein fehlgeschlagener Lauf. Der Lauf sagt dir, welcher Schritt fehlgeschlagen ist, und bietet an, dort weiterzumachen oder es erneut zu versuchen. Du kannst einen Lauf auch abbrechen, selbst einen, der schon in Apples Warteschlange steht; dort zieht Uprate die Einreichung zur Prüfung für dich zurück.

Was es kostet

Der Submission-Agent ist in jedem Plan verfügbar, auch im kostenlosen. Die Repository-Analyse bei einer ersten Veröffentlichung ist eine Aktion für 5 Credits für den gesamten Satz an Analyzern, das ASO-Audit sind weitere 5, und ein Fix-Prompt kostet 2. Builds laufen über dein Expo-Konto oder kommen von dir, sie werden also nicht in Uprate-Credits gezählt.

Wo das hingehört

Der Submission-Agent ist das Zweite, was man nach dem Verbinden der Stores einrichtet. Wovor er dich schützt, steht in Wie lange das App-Store-Review dauert und in den Ablehnungs-Guides auf diesem Blog, und wie er neben Rezensions-Inbox und Listing-Entwürfen steht, in Store-Operations fahren, ohne extra jemanden für Ops einzustellen.