Saison 2026: täglich aktualisiert 💡 Eigene App, Webseite, KI-Agenten oder Digital-Idee? Das Team hinter BreisgauStraussen entwickelt sie für dich!💡 Eigene App oder KI-Agenten? Wir entwickeln sie für dich!

Deploy, Convert & Scale: Ratgeber

Release-Pipeline für iOS und Android mit GitHub Actions

Von John Caffier, Lead AI Code Engineer bei jocapps3 Min. Lesezeit

Manuelle Releases funktionieren, bis sie es nicht mehr tun: Der eine Rechner mit dem richtigen Zertifikat ist im Urlaub, jemand vergisst die Build-Nummer, ein Upload bricht ab. Eine automatisierte Release-Pipeline löst diese Probleme dauerhaft. GitHub Actions ist dafür eine naheliegende Wahl, besonders wenn Ihr Code ohnehin dort liegt und Claude Code bereits per GitHub-Integration Pull Requests bearbeitet. Wir zeigen, wie eine robuste Pipeline für iOS und Android aussieht, was der Agent beitragen kann und wo Sie Sicherheitsgrenzen ziehen sollten.

Die Architektur einer guten Pipeline

Eine bewährte Pipeline trennt drei Stufen. Bei jedem Pull Request laufen Lint, Tests und ein Debug-Build, damit Fehler früh auffallen. Beim Merge in den Hauptzweig entsteht ein Beta-Build, der automatisch an TestFlight und den internen Test-Track von Google Play geht. Ein Git-Tag oder eine manuelle Freigabe löst schließlich den Produktions-Release aus.

Für iOS brauchen Sie macOS-Runner, die bei GitHub teurer und langsamer sind als Linux-Runner. Planen Sie deshalb, nur dort auf macOS zu bauen, wo es nötig ist. Android-Builds, Tests und Web-Builds laufen günstiger auf Linux. Als Alternativen kommen Codemagic, Bitrise oder Xcode Cloud in Frage, die besonders für mobile Projekte optimiert sind.

Schritt für Schritt zur Pipeline

Claude Code kann Workflow-Dateien und fastlane-Lanes schreiben. Gehen Sie dabei in dieser Reihenfolge vor:

  1. Lassen Sie fastlane-Lanes für Beta und Produktion erstellen und lokal erfolgreich testen, bevor Sie an die CI denken.
  2. Legen Sie in GitHub die nötigen Secrets an: App-Store-Connect-API-Schlüssel, Zugang zum match-Speicher, Keystore als Base64 und das JSON des Play-Dienstkontos.
  3. Lassen Sie Claude Code die Workflow-Dateien für Pull Requests, Beta und Release schreiben, mit Caching für Abhängigkeiten.
  4. Richten Sie für den Produktions-Workflow eine GitHub-Umgebung mit erforderlicher manueller Freigabe ein.
  5. Testen Sie die Pipeline zuerst mit einem Beta-Release und prüfen Sie Laufzeiten, Logs und hochgeladene Artefakte.

Sicherheit: Was der Agent nicht sehen darf

Eine Release-Pipeline hat Zugriff auf alles, was Ihre App im Store ausmacht. Deshalb gelten strenge Regeln. Secrets werden ausschließlich in GitHub hinterlegt und niemals in Workflow-Dateien, Logs oder Prompts ausgegeben. Workflows aus Forks dürfen keinen Zugriff auf Secrets haben. Der API-Schlüssel für App Store Connect sollte die geringstmögliche Rolle haben.

Wenn Claude Code selbst über GitHub Actions in Ihrem Repository arbeitet, etwa um Issues zu bearbeiten, trennen Sie diese Workflows strikt von den Release-Workflows. Der Agent darf Pull Requests erstellen, aber nicht ohne menschliche Freigabe Produktions-Releases anstoßen. Geschützte Branches und Pflicht-Reviews setzen diese Trennung technisch durch.

Häufige Fehler und schnelle Lösungen

Viele Pipelines scheitern beim ersten Lauf an der iOS-Signierung, weil auf dem Runner kein Schlüsselbund angelegt wurde oder das Profil nicht zur App ID passt. Ein anderer Klassiker sind unterschiedliche Xcode-Versionen zwischen lokaler Entwicklung und Runner. Legen Sie die Version im Workflow explizit fest. Bei Android scheitern Uploads oft daran, dass das Dienstkonto in der Play Console nicht die nötigen Rechte für die App hat.

Geben Sie Claude Code bei Fehlschlägen das vollständige Log des fehlgeschlagenen Schritts. Der Agent erkennt die Ursache meist schnell und schlägt eine Korrektur vor. Lassen Sie ihn außerdem Laufzeiten optimieren, etwa durch Caching von Abhängigkeiten oder parallele Jobs.

Hilfreich ist außerdem eine Benachrichtigung bei Erfolg und Fehlschlag, etwa in Ihrem Team-Chat. So weiß jeder sofort, ob ein Beta-Build bei den Testern angekommen ist oder ob jemand eingreifen muss.

Pipeline als Teil des Produkts

Eine gute Pipeline ist kein Projekt, das einmal fertig wird. Neue Xcode-Versionen, geänderte Runner-Images und neue Store-Anforderungen erfordern regelmäßige Pflege. Dokumentieren Sie den Ablauf in der CLAUDE.md, damit auch der Agent bei späteren Änderungen den Kontext kennt.

appsubmitter richtet Release-Pipelines mit fastlane und GitHub Actions, GitLab CI, Bitrise, Codemagic oder Xcode Cloud in Ihrem eigenen Account ein, inklusive Code Signing und Play App Signing. Möchte Ihr Team lernen, Coding-Agenten sicher in CI/CD einzusetzen, bietet neooutput passende Workshops. Vereinbaren Sie ein kostenloses 15-Minuten-Erstgespräch.

Häufige Fragen

Brauche ich für iOS-Builds in GitHub Actions einen eigenen Mac?

Nein, GitHub stellt macOS-Runner bereit. Diese verbrauchen allerdings mehr Kontingent als Linux-Runner. Alternativ können Sie einen eigenen Mac als selbst gehosteten Runner einbinden.

Wie lange dauert ein typischer Pipeline-Lauf?

Das hängt stark von App-Größe und Caching ab. Ein iOS-Build mit Upload dauert meist deutlich länger als ein Android-Build. Mit gutem Caching lassen sich die Zeiten spürbar reduzieren.

Kann Claude Code die Pipeline selbst reparieren?

Claude Code kann Logs analysieren und Korrekturen als Pull Request vorschlagen. Die Prüfung und Freigabe sollte bei sicherheitskritischen Release-Workflows aber immer bei einem Menschen liegen.