Så automatiserar du App Store-skärmbilder i CI/CD

Varför ska du automatisera skärmbilder över huvud taget?

De flesta team behandlar App Store- och Google Play-skärmbilder som en engångsprodukt: en designer skissar dem i Figma, en marknadsförare lägger in dem i App Store Connect, och ingen rör dem igen förrän nästa stora omdesign. Den modellen havererar i samma stund som du släpper appen på fler än ett språk. Med 13 språk som stöds, tre obligatoriska iPhone-storlekar, två iPad-storlekar plus telefon och surfplatta på Google Play tittar du på över 100 PNG-filer för en enda release. Multiplicera med varje copyändring, varje kampanj, varje A/B-testvariant — och matematiken slutar fungera.

Att automatisera i CI/CD gör skärmbilderna till en byggartefakt precis som vilken annan binär som helst. De versionshanteras, är reproducerbara och kopplade till en commit. När marknadsföring ändrar en bildtext bygger pipelinen om varje språk och laddar upp dem — inga manuella Photoshop-sessioner, ingen drift mellan språkversioner och inga avslag vid inlämning för att någon glömde en variant för 6,7-tums iPhone.

Hur ser pipelinen faktiskt ut?

Formen på en ren CI-pipeline för skärmbilder består av tre steg: fånga, rendera och leverera. Att fånga är din befintliga UI-testsvit — XCUITest på iOS, Espresso på Android, Detox eller Maestro för React Native. Rendering är ett Screenshots.live API-anrop per språk som komponerar dina råa bildrutor på en mall som du designat en gång. Leverans är de befintliga Fastlane-actions deliver och supply som du redan använder för att skicka binärer.

Screenshots.live REST-renderings-API är hörnstenen. Du skickar in råa skärmbilder en gång och får tillbaka varje enhetsstorlek, varje språk och varje variant — fullt inramade, textade och lokaliserade. Ingen huvudlös webbläsare, ingen Puppeteer, ingen manuell omskalning.

Hur kopplar du ihop det med Fastlane?

Fastlane är det självklara verktyget för release-automatisering på iOS och Android. Vi tillhandahåller en officiell Fastlane-plugin som omsluter renderings-API:et i en enda action. Installera den från din projektrot:

fastlane add_plugin screenshotslive

Lägg sedan till en lane i din Fastfile som fångar, renderar och skriver det renderade resultatet:

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

Pluginen sköter uppladdningar, polling efter färdigställande och nedladdning parallellt. En typisk rendering med 5 språk och 3 enheter blir klar på 60–90 sekunder.

Hur kör du detta på GitHub Actions?

Lägg in din lane i en workflow-fil. Workflowen nedan körs vid varje tag-push som matchar v* och vid ett nattligt schema, så ett manuellt git tag v1.2.0 && git push --tags är allt som krävs för att utlösa en ny rendering.

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 team som föredrar en GitHub Action utan Fastlane publicerar vi även en fristående GitHub Action som pratar direkt med API:et:

- 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

Hur är det med Bitrise?

Bitrise-användare får samma lane via det befintliga Fastlane-steget. Lägg till en Secret som heter SCREENSHOTSLIVE_API_TOKEN i din Bitrise-arbetsyta och klistra sedan in detta i din 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

Hur håller du nere byggtiderna?

Det långsamma i en CI-pipeline för skärmbilder är renderingen, inte uppladdningen. Tricket är att cacha renderingar efter innehållshash så att oförändrade språk återanvänder tidigare resultat. Screenshots.live returnerar en stabil renderHash i svaret — använd den som cachenyckel:

• Mallversion + språk + variant-hash → cachenyckel
• Renderade PNG-bytes → cachevärde
• Cache-TTL: 30 dagar, eller tills mallen publiceras om

På GitHub Actions, använd actions/cache@v4 med en nyckel som härleds från ditt mall-ID och språklistan. De flesta release-byggen hoppar över rendering helt och bygger bara om det språk som faktiskt har ändrats.

Hur validerar du resultatet innan du skickar in det?

Både Apple och Google avvisar skärmbilder tyst när formatkontrollerna fallerar: en PNG med alfakanal, en JPEG kodad som CMYK, eller en skärmbild för 6,7-tums iPhone som är en pixel för liten. Bygg ett 20 rader långt lint-steg som fångar detta före inlämning:

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

Bör du köra det enligt schema?

Ja. En nattlig cron innebär att skärmbilder genereras om varje gång din mall ändras — oavsett om ändringen kom från en designer i editorn, en copyuppdatering från marknadsföring eller att ett nytt språk lades till. Utan ett schema driver butikslistningarna ifrån din verkliga produkt, och någon måste komma ihåg att trycka in ett färskt bygge före varje inlämning.

Kombinera schemat med en avisering till Slack eller e-post vid fel. En trasig rendering klockan 04:00 UTC blir en notis 07:00 lokal tid — inte en releaseblockerare som upptäcks 17:00 samma dag som du tänkt skicka in.

Hur är det med Android, React Native och Flutter?

Pipelinen är plattformsoberoende på rendringssidan — bara fångststeget ändras. För Android, byt ut capture_screenshots mot Fastlane screengrab och din Espresso-svit. För React Native, använd Detox-snapshots. För Flutter, använd integration_test-skärmbilder. Alla producerar råa PNG:er som Screenshots.live behandlar identiskt.

Läs mer i vår guide för stöd över flera plattformar för fångstkonfiguration på varje stack.

Vart går du härifrån?

När din CI-pipeline tillförlitligt levererar skärmbilder är nästa fråga vilka skärmbilder som vinner. Kombinera den här pipelinen med guiden för A/B-testning för att leverera varianter enligt schema och mäta konvertering. Para ihop den med guiden för lokalisering för att lägga till 30+ språk utan 30+ pipelines.

Auktoritativa källor för vidare läsning: Fastlane iOS screenshots-dokumentation, Fastlane deliver-action och de officiella App Store Connect-specifikationerna för skärmbilder.