Wie man App-Store-Screenshots in CI/CD automatisiert

Warum überhaupt Screenshots automatisieren?

Die meisten Teams behandeln App-Store- und Google-Play-Screenshots als einmaliges, handgefertigtes Asset: Ein Designer baut sie in Figma, ein Marketer legt sie in App Store Connect ab, und niemand fasst sie an, bis zum nächsten großen Redesign. Dieses Modell zerbricht in dem Moment, in dem Sie an mehr als eine Sprache ausliefern. Mit 13 unterstützten Sprachen, drei erforderlichen iPhone-Größen, zwei iPad-Größen sowie Smartphone und Tablet bei Google Play stehen Sie über 100 PNG-Dateien für ein einziges Release gegenüber. Multiplizieren Sie das mit jeder Text-Änderung, jeder Promo, jeder A/B-Test-Variante, und die Mathematik geht nicht mehr auf.

Die Automatisierung in CI/CD macht Screenshots zu einem Build-Artefakt wie jedes andere Binary. Sie sind versioniert, reproduzierbar und an einen Commit gebunden. Wenn Marketing eine Bildunterschrift ändert, baut die Pipeline jede Sprache neu auf und lädt sie hoch — keine manuellen Photoshop-Sitzungen, keine Asset-Drift zwischen Sprachen, keine Ablehnung bei der Einreichung, weil jemand eine 6,7-Zoll-iPhone-Variante vergessen hat.

Wie sieht die Pipeline tatsächlich aus?

Die Form einer sauberen CI-Screenshot-Pipeline besteht aus drei Stufen: Capture, Render und Deliver. Capture ist Ihre bestehende UI-Test-Suite — XCUITest auf iOS, Espresso auf Android, Detox oder Maestro für React Native. Render ist ein Screenshots.live-API-Aufruf pro Sprache, der Ihre Rohframes auf eine Vorlage komponiert, die Sie einmal designt haben. Deliver sind die bestehenden Fastlane-deliver- und supply-Actions, die Sie bereits zum Pushen von Binaries verwenden.

Die REST-Rendering-API von Screenshots.live ist der Schlussstein. Sie senden Roh-Screenshots einmal und erhalten jede Gerätegröße, jede Sprache und jede Variante zurück — vollständig gerahmt, mit Bildunterschriften und lokalisiert. Kein Headless-Browser, kein Puppeteer, keine manuelle Größenanpassung.

Wie verdrahtet man es mit Fastlane?

Fastlane ist das kanonische iOS-/Android-Release-Automatisierungstool. Wir liefern ein offizielles Fastlane-Plugin, das die Rendering-API in einer einzigen Action verpackt. Installieren Sie es aus Ihrem Projekt-Root:

fastlane add_plugin screenshotslive

Fügen Sie dann Ihrem Fastfile eine Lane hinzu, die erfasst, rendert und die gerenderte Ausgabe schreibt:

lane :render_screenshots do
  # 1. Capture raw frames with XCUITest
  capture_screenshots(
    workspace: "MyApp.xcworkspace",
    scheme: "MyAppUITests",
    devices: ["iPhone 16 Pro Max", "iPad Pro 12.9-inch"],
    languages: ["en-US", "de-DE", "es-ES", "fr-FR", "pt-BR"]
  )

  # 2. Send raw frames to Screenshots.live, get framed PNGs back
  screenshotslive_render(
    api_token: ENV["SCREENSHOTSLIVE_API_TOKEN"],
    template_id: "tpl_app_release_v3",
    input_dir: "./fastlane/screenshots",
    output_dir: "./fastlane/rendered",
    locales: ["en", "de", "es", "fr", "pt"],
    devices: ["iphone-6.7", "iphone-6.1", "ipad-12.9"]
  )

  # 3. Push to App Store Connect
  deliver(
    screenshots_path: "./fastlane/rendered",
    skip_binary_upload: true,
    skip_metadata: false
  )
end

Das Plugin übernimmt Uploads, das Polling auf Fertigstellung und parallelen Download. Ein typisches 5-Sprachen-, 3-Geräte-Rendering ist in 60–90 Sekunden fertig.

Wie führt man das auf GitHub Actions aus?

Legen Sie die Lane in eine Workflow-Datei. Der untenstehende Workflow läuft bei jedem Tag-Push, der zu v* passt, und nach einem nächtlichen Zeitplan, sodass ein manuelles git tag v1.2.0 && git push --tags alles ist, was Sie brauchen, um ein frisches Rendering auszulösen.

name: Render Store Screenshots

on:
  push:
    tags: ["v*"]
  schedule:
    - cron: "0 4 * * *"  # nightly at 04:00 UTC
  workflow_dispatch:

jobs:
  render:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4

      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: "3.2"
          bundler-cache: true

      - name: Render screenshots
        env:
          SCREENSHOTSLIVE_API_TOKEN: ${{ secrets.SCREENSHOTSLIVE_API_TOKEN }}
          FASTLANE_USER: ${{ secrets.FASTLANE_USER }}
          FASTLANE_PASSWORD: ${{ secrets.FASTLANE_PASSWORD }}
        run: bundle exec fastlane render_screenshots

      - name: Upload rendered artifacts
        uses: actions/upload-artifact@v4
        with:
          name: store-screenshots
          path: fastlane/rendered/

Für Teams, die eine GitHub Action ohne Fastlane bevorzugen, veröffentlichen wir auch eine eigenständige GitHub Action, die direkt mit der API spricht:

- uses: Screenshots-Live/render-screenshots-action@v1
  with:
    api-token: ${{ secrets.SCREENSHOTSLIVE_API_TOKEN }}
    template-id: tpl_app_release_v3
    locales: en,de,es,fr,pt,it,nl
    devices: iphone-6.7,iphone-6.1,ipad-12.9
    output-dir: ./screenshots

Was ist mit Bitrise?

Bitrise-Nutzer erhalten dieselbe Lane über den bestehenden Fastlane-Step. Fügen Sie ein Secret namens SCREENSHOTSLIVE_API_TOKEN in Ihrem Bitrise-Workspace hinzu und legen Sie dies in Ihre bitrise.yml:

workflows:
  render-screenshots:
    steps:
    - activate-ssh-key@4: {}
    - git-clone@8: {}
    - script@1:
        title: Install Fastlane plugins
        inputs:
        - content: |-
            #!/usr/bin/env bash
            bundle install
            bundle exec fastlane add_plugin screenshotslive
    - fastlane@3:
        inputs:
        - lane: render_screenshots
        - work_dir: "$BITRISE_SOURCE_DIR"
    - deploy-to-bitrise-io@2:
        inputs:
        - deploy_path: ./fastlane/rendered

Wie hält man die Build-Zeiten niedrig?

Der langsame Teil jeder CI-Screenshot-Pipeline ist das Rendern, nicht das Hochladen. Der Trick ist, Renderings nach Content-Hash zu cachen, sodass unveränderte Sprachen vorherige Ausgaben wiederverwenden. Screenshots.live gibt einen stabilen renderHash in der Antwort zurück — verwenden Sie ihn als Cache-Schlüssel:

• Vorlagenversion + Sprache + Varianten-Hash → Cache-Schlüssel
• Gerenderte PNG-Bytes → Cache-Wert
• Cache-TTL: 30 Tage oder bis die Vorlage erneut veröffentlicht wird

Verwenden Sie auf GitHub Actions actions/cache@v4 mit einem Schlüssel, der aus Ihrer Template-ID und der Sprachliste abgeleitet wird. Die meisten Release-Builds überspringen das Rendering komplett und bauen nur die Sprache neu, die sich tatsächlich geändert hat.

Wie validiert man die Ausgabe vor der Einreichung?

Apple und Google lehnen Screenshots beide stillschweigend ab, wenn sie Formatprüfungen nicht bestehen: ein PNG mit Alphakanal, ein als CMYK kodiertes JPEG oder ein 6,7-Zoll-iPhone-Screenshot, der einen Pixel zu kurz ist. Bauen Sie einen 20-zeiligen Lint-Step, der diese vor der Einreichung abfängt:

require "chunky_png"

Dir.glob("./fastlane/rendered/**/*.png").each do |path|
  png = ChunkyPNG::Image.from_file(path)
  raise "alpha channel: #{path}" if png.metadata["ColorType"] == 6
  raise "too large: #{path}"     if File.size(path) > 30 * 1024 * 1024
  raise "wrong size: #{path}"    if png.width < 1242
end

Sollte man ihn nach Zeitplan ausführen?

Ja. Ein nächtlicher Cron bedeutet, dass Screenshots regeneriert werden, wann immer sich Ihre Vorlage ändert — egal ob die Änderung von einem Designer im Editor, einer Text-Aktualisierung von Marketing oder einer neu hinzugefügten Sprache stammt. Ohne Zeitplan driften Store-Listings aus dem Takt mit Ihrem echten Produkt, und jemand muss daran denken, vor jeder Einreichung einen frischen Build zu pushen.

Kombinieren Sie den Zeitplan mit einer Slack- oder E-Mail-Benachrichtigung bei Fehler. Ein gebrochenes Rendering um 04:00 UTC ist eine Benachrichtigung um 07:00 lokal — nicht ein Release-Blocker, der um 17:00 an dem Tag entdeckt wird, an dem Sie ausliefern wollten.

Was ist mit Android, React Native und Flutter?

Die Pipeline ist auf der Rendering-Seite plattformagnostisch — nur die Capture-Stufe ändert sich. Für Android tauschen Sie capture_screenshots gegen Fastlane screengrab und Ihre Espresso-Suite. Für React Native verwenden Sie Detox-Snapshots. Für Flutter verwenden Sie integration_test-Screenshots. Alle erzeugen rohe PNGs, die Screenshots.live identisch behandelt.

Mehr lesen Sie in unserem Multi-Plattform-Support-Leitfaden für die Capture-Konfiguration auf jedem Stack.

Wohin geht es von hier aus?

Sobald Ihre CI-Pipeline zuverlässig Screenshots ausliefert, ist die nächste Frage, welche Screenshots gewinnen. Kombinieren Sie diese Pipeline mit dem A/B-Test-Leitfaden, um Varianten nach Zeitplan auszuliefern und die Conversion zu messen. Paaren Sie sie mit dem Lokalisierungs-Leitfaden, um 30+ Sprachen ohne 30+ Pipelines hinzuzufügen.

Maßgebliche Referenzen zur weiteren Lektüre: Fastlane-iOS-Screenshots-Doku, Fastlane-deliver-Action und die offiziellen App-Store-Connect-Screenshot-Spezifikationen.