Zum Inhalt springen
← Alle Beiträge

21. August 2026

Zwei-Faktor killt deine Automatisierung

Das erste Release-Skript scheitert nicht am Code. Es scheitert am SMS-Code, auf den es wartet. Warum Store-Automatisierung mit einem Schlüssel anfängt und nicht mit einem Login.

Du hast es satt, für jedes Update durch zwei Konsolen zu klicken. Also schreibst du ein Skript. Anmelden, Build hochladen, Metadaten setzen, einreichen. Klingt nach einem Nachmittag Arbeit und danach nie wieder.

Das Skript läuft an, meldet sich an und bleibt stehen. Es wartet auf einen sechsstelligen Code, der gerade auf dein Telefon gekommen ist.

Eine Automatisierung, die bei jedem Durchlauf einen Menschen braucht, ist keine.

Der Fehler steckt in der ersten Zeile

Der Reflex ist, Apple-ID und Passwort ins Skript zu legen. Genau das ist der Punkt, an dem es nicht weitergeht. Zwei-Faktor ist bei Entwickler-Accounts Pflicht, und das ist gut so. Nur lässt sich ein SMS-Code nicht skripten, und jede Bastelei drumherum ist entweder brüchig oder eine schlechte Idee.

Die Lösung ist nicht, das Login zu automatisieren. Die Lösung ist, kein Login zu benutzen.

Apple: ein Schlüssel, drei Angaben

In App Store Connect legst du unter den Integrationen einen API-Schlüssel an. Du bekommst drei Dinge, und du brauchst alle drei:

  • die Schlüssel-ID, eine kurze Kennung
  • die Issuer-ID, die für dein ganzes Team gilt
  • die .p8-Datei, den eigentlichen privaten Schlüssel

Damit meldet sich dein Skript an, ohne Passwort und ohne Telefon.

Vier Dinge, die beim ersten Mal danebengehen:

Die .p8 gibt es genau einmal. Apple lässt dich den privaten Schlüssel nur ein einziges Mal herunterladen. Wer den Download wegklickt oder die Datei später verliert, legt einen neuen Schlüssel an. Es gibt keinen zweiten Versuch.

Die Datei gehört nicht ins Repository. Das ist ein privater Schlüssel mit Schreibrechten auf deine Store-Einträge. Er wandert in die Geheimnis-Verwaltung deiner Pipeline, nicht neben den Quellcode. Wenn deine KI ihn beim Aufräumen hilfsbereit mit eincheckt, merkst du das nicht von selbst.

Die Rolle entscheidet, was der Schlüssel darf. Vergib die kleinste Rolle, mit der dein Ablauf durchläuft. Ein Schlüssel, der nur Builds hochladen soll, braucht keine Rechte, mit denen sich Verträge und Auszahlungen ändern lassen.

Die Anmeldung ist kurzlebig. Aus dem Schlüssel entsteht ein Token, und Apple lässt höchstens 20 Minuten Gültigkeit zu. Für die meisten Werkzeuge ist das egal, die erneuern es selbst. Wer den Token von Hand baut und in einer langen Pipeline weiterreicht, bekommt Fehler mitten im Ablauf, die aussehen, als wäre der Schlüssel falsch. Er ist nur alt.

Google: zwei Konsolen, und die zweite vergisst jeder

Bei Google läuft es über ein Dienstkonto, und der Weg geht durch zwei getrennte Oberflächen. Das Konto entsteht in der Google Cloud Console, die Berechtigung dafür vergibst du danach in der Play Console.

Wer den zweiten Schritt vergisst, hat einen gültigen Schlüssel ohne Zugriff. Die Fehlermeldung sieht nach falschem Schlüssel aus, und dann tauscht man stundenlang etwas aus, das nie das Problem war.

Fang mit Lesen an, nicht mit Hochladen

Das ist der Teil, den ich jedem mitgebe, der damit anfängt.

Der erste Automatisierungsschritt ist nicht das Release. Es ist eine Abfrage. Schreib dir ein Skript, das nichts weiter tut, als die aktuellen Angaben deiner App auszulesen und hinzuschreiben. Name, Version, Beschreibung, Zustand.

Das hat drei Vorteile auf einmal. Es beweist, dass Schlüssel, Rolle und Rechte stimmen. Es kann nichts kaputtmachen, weil es nichts ändert. Und du siehst zum ersten Mal, wie die Daten wirklich aussehen, statt wie sie in der Oberfläche dargestellt werden.

Erst wenn das Lesen sauber läuft, lohnt sich der Schritt zum Schreiben. Wer umgekehrt anfängt, sucht Fehler in seinem Release-Ablauf, die in Wahrheit Rechte-Fehler waren.

Was das eigentlich freischaltet

Mit einem funktionierenden Zugang hört das Klicken auf, aber der größere Gewinn ist ein anderer: Deine Store-Angaben werden zu Dateien. Beschreibungstexte, Schlüsselwörter, Screenshots und Untertitel liegen dann in deinem Projekt statt in einer Weboberfläche. Damit hast du Verlauf, Vergleich und einen Weg zurück. Eine neue Sprache ist danach ein Datensatz, keine zwölf Klickrunden.

Das ist der Unterschied zwischen “ich habe das Hochladen automatisiert” und “mein Store-Eintrag ist Teil meines Projekts”.

Der Guide zur Store-Automatisierung geht genau diesen Weg durch: Zugang, Auslesen, Metadaten und Screenshots als Code, dann die Release-Pipeline. Dazu die Felder, an denen Einreichungen still hängenbleiben, ohne dass jemand dir sagt warum.

Heute reicht der erste Schritt: Schlüssel anlegen, kleinste Rolle vergeben, ein Leseskript schreiben. Wenn das durchläuft, ist der schwierige Teil vorbei.

Michael Schreier
Michael Schreier

Diplom-Informatiker · 25 Jahre Entwicklung · LinkedIn

app-storeautomatisierungreleaseci
praxis-guides
$ guide --open "App Store & Play Store automatisieren"
[i] Releases, Screenshots und Metadaten laufen über die Store-APIs statt von Hand durch die Konsolen. Ein neuer Release ist ein Befehl, kein Nachmittag.

PDF plus Beispiele · 197 € · framework-unabhängig

App Store & Play Store automatisieren
Michael Schreier

Fragen zum Thema?

Schreib mir — ich freue mich auf den Austausch.