Automatisierung & CI/CD

Die meisten Befehle, die eine Bestätigung verlangen, unterstützen --yes / -y zum Überspringen von Abfragen, wodurch sie für CI/CD-Pipelines und Skripte geeignet sind.

ascelerate apps build attach-latest <bundle-id> --yes
ascelerate apps review submit <bundle-id> --yes

warnung

Bei Verwendung von --yes mit Provisioning-Befehlen müssen alle erforderlichen Argumente explizit angegeben werden — der interaktive Modus ist deaktiviert.

Probelauf

Hängen Sie --dry-run an, um einen Befehl oder einen ganzen Workflow auszuprobieren, ohne etwas in App Store Connect zu ändern. Die Option funktioniert an jeder Stelle der Befehlszeile, und ASCELERATE_DRY_RUN=1 bewirkt dasselbe. Lesende Anfragen werden wie gewohnt gesendet, sodass Abfragen und Prüfungen mit Ihren echten Daten laufen. Jede schreibende Anfrage wird jedoch vor dem Senden angehalten: ascelerate gibt ihre Methode, ihren Pfad und ihren JSON-Body auf stderr aus und meldet, dass die Anfrage nicht gesendet wurde.

ascelerate apps localizations import <bundle-id> --file localizations.json --yes --dry-run
ascelerate run-workflow release.txt --yes --dry-run
ASCELERATE_DRY_RUN=1 ascelerate run-workflow release.txt --yes   # dasselbe, etwa für einen ganzen CI-Job

• Ein Befehl bricht bei der ersten angehaltenen Schreibanfrage ab oder meldet, wenn er Elemente einzeln abarbeitet, jede angehaltene Anfrage als fehlgeschlagen.
• media upload behandelt angehaltene Schreibanfragen als erledigt und macht weiter, sodass die Schreibanfragen jeder Datei angezeigt werden; am Ende nennt es, wie viele Dateien hochgeladen würden.
• In run-workflow beendet ein Schritt, dessen Schreibanfragen angehalten wurden, den Workflow nicht, sodass ein einziger Durchlauf die Schreibanfragen aller Schritte zeigt. Ein Schritt, der auf etwas angewiesen ist, das ein früherer Schritt erstellt hätte (etwa eine neue Version oder einen hochgeladenen Build), kann trotzdem fehlschlagen.
• In einer Workflow-Datei gilt --dry-run bei einem einzelnen Schritt nur für diesen Schritt.
• builds upload überspringt den Upload. builds archive und builds validate laufen weiterhin, da sie in App Store Connect nichts ändern.

API-Ratenlimit

App Store Connect erlaubt 3.600 API-Anfragen pro Stunde für Ihren API-Schlüssel, gezählt über eine gleitende Stunde. Verbraucht ein langer Befehl (ein großer Medien-Upload, das Aufräumen der Bibliothek, ein Preisimport) sie, wartet ascelerate, bis App Store Connect wieder Anfragen zulässt, zeigt an, wann es weitergeht, und macht dann weiter. Mit Ctrl-C brechen Sie stattdessen ab.

In CI ist ein Abbruch oft besser als Warten: Setzen Sie ASCELERATE_MAX_RATE_LIMIT_WAIT auf die Sekunden, die ein Durchlauf insgesamt höchstens warten darf (0 bricht bei der ersten begrenzten Anfrage ab).

ASCELERATE_MAX_RATE_LIMIT_WAIT=600 ascelerate run-workflow release.txt --yes

ascelerate rate-limit zeigt, wie viele Anfragen übrig sind; dieser Befehl wartet nie.

Upload in Teilen

App Store Connect nimmt hochgeladene Dateien (Screenshots, Vorschauen, Builds mit builds upload --api und andere Medien) in Teilen an. ascelerate sendet sie nacheinander und lässt so Bandbreite für alles andere auf der Verbindung. Bei einer schnellen Verbindung mit hoher Latenz zu Apples Speicher kann es schneller gehen, mehrere gleichzeitig zu senden: Setzen Sie ASCELERATE_PARALLEL_CHUNKS auf die Anzahl der Teile, die gleichzeitig gesendet werden.

ASCELERATE_PARALLEL_CHUNKS=4 ascelerate apps media upload <bundle-id> media/

Xcode-Signierung in CI

Sowohl builds archive als auch der Export von Archiv zu IPA übergeben -allowProvisioningUpdates an xcodebuild. Ohne dieses Flag verwendet xcodebuild nur lokal zwischengespeicherte Provisioning-Profile und lädt keine aktualisierten Profile aus dem Developer Portal herunter.

Für CI-Umgebungen ohne Xcode-GUI-Anmeldung übergeben Sie Authentifizierungs-Flags:

ascelerate builds archive \
  --authentication-key-path /path/to/AuthKey.p8 \
  --authentication-key-id YOUR_KEY_ID \
  --authentication-key-issuer-id YOUR_ISSUER_ID

JSON-Ausgabe

Lesebefehle unterstützen --json für maschinenlesbare Ausgabe, die sich direkt mit jq, in Skripten und von KI-Agenten weiterverarbeiten lässt:

ascelerate apps list --json
ascelerate apps info <bundle-id> --json
ascelerate apps versions <bundle-id> --json
ascelerate apps review preflight <bundle-id> --json
ascelerate apps review status <bundle-id> --json
ascelerate builds list --bundle-id <bundle-id> --json
ascelerate testflight builds <bundle-id> --json
ascelerate testflight status <bundle-id> --json
ascelerate reviews list <bundle-id> --json
ascelerate reviews info <review-id> --json
ascelerate iap list <bundle-id> --json
ascelerate iap info <bundle-id> <product-id> --json
ascelerate iap pricing show <bundle-id> <product-id> --json
ascelerate sub groups <bundle-id> --json
ascelerate sub list <bundle-id> --json
ascelerate sub info <bundle-id> <product-id> --json
ascelerate sub pricing show <bundle-id> <product-id> --json
ascelerate rate-limit --json

Ausgabekonventionen:

• Listenbefehle geben auf oberster Ebene ein JSON-Array aus; Detailbefehle ein einzelnes Objekt.
• Enum-Werte sind rohe API-Konstanten (WAITING_FOR_REVIEW, IOS), Datumsangaben sind ISO 8601, und jede Ressource enthält ihre id.
• Null-Felder werden weggelassen; leere Ergebnisse ergeben [] — niemals Fließtext.
• Warnungen werden zu booleschen Werten: iap info und sub info geben "hasPricing": false statt einer Warnmeldung aus.
• --json impliziert den nicht-interaktiven Modus: Befehle, die sonst nachfragen würden (etwa um zwischen Plattformen zu unterscheiden), brechen stattdessen mit einem Fehler ab — übergeben Sie --platform oder andere Flags, um Eindeutigkeit herzustellen.
• Fehler gehen an stderr, sodass stdout immer gültiges JSON ist.

Beispiel — unbeantwortete Rezensionen zählen:

ascelerate reviews list <bundle-id> --json | jq '[.[] | select(.response == null)] | length'

Exit-Codes

Befehle beenden sich bei Fehlern mit einem Exit-Code ungleich Null, sodass sie sicher in Skripten mit set -e oder &&-Verkettung verwendet werden können. Der preflight-Befehl gibt speziell einen Exit-Code ungleich Null zurück, wenn eine Prüfung fehlschlägt, sodass Sie Einreichungen davon abhängig machen können:

ascelerate apps review preflight <bundle-id> && ascelerate apps review submit <bundle-id>

Mit --json gibt preflight einen strukturierten Bericht aus ({"passed": false, "checks": [{"group", "name", "passed", "detail", "skipped"}]}, wobei skipped nur bei aus dem Verkauf genommenen Produkten erscheint, die als bestanden zählen) und behält dabei das gleiche Exit-Code-Verhalten bei — ideal für CI-Gates, die melden müssen, welche Prüfung fehlgeschlagen ist.