Problemet: 20 apper, 20 merker, hundrevis av skjermbilder

For noen år siden jobbet jeg som utvikler i en oppstart der vi bygde en whitelabel mobilapp. En kodebase, men 20 forskjellige kunder — hver med sin egen merkevareidentitet, farger, logoer og App Store-oppføringer. Hver trengte sitt eget sett med polerte App Store- og Google Play-skjermbilder.

Hvis du noen gang har publisert en app, kjenner du rutinen: Apple vil ha skjermbilder for hver enhetsstørrelse (6.7", 6.5", 5.5", iPad Pro, iPad...), Google Play vil ha sitt eget sett, og hvis du støtter flere språk, multipliserer du alt igjen. Multipliser nå det med 20 kunder.

Vi snakker om tusenvis av skjermbilder som måtte genereres, innrammet i enhetsmockups, merket med riktige farger og lastet opp — ved hver releasesyklus.

Hva vi hadde: automatiserte skjermbilder i pipelinen

De rå skjermbildene i seg selv var ikke problemet. Det hadde vi løst. UI-testene våre, som kjørte i GitLab CI-pipelinen vår, startet hver appvariant, navigerte gjennom nøkkelskjermene og tok skjermbilder automatisk. Fastlanes snapshot (iOS) og screengrab (Android) tok seg av det tunge arbeidet.

Så vi hadde hundrevis av rå PNG-filer som landet i pipeline-artefaktene våre etter hvert bygg. Flott. Men rå skjermbilder havner ikke i App Store. De må bearbeides — plasseres inne i enhetsvinduer, gis en bakgrunn som matcher kundens merkevare, legges over med markedsføringstekst og eksporteres i de eksakte pikselstørrelsene hver butikk krever.

Smertepunktene

1. Designerflaskehalsen

Designeren vår var talentfull, men å be ham manuelt oppdatere Figma-filer for 20 merker ved hver release var absurd. Han brukte dager bare på å bytte ut skjermbilder og justere farger. Og hvis en kunde endret merkevareidentiteten sin midt i syklusen? Begynn på nytt.

2. Ingen tid til å bygge interne verktøy

Vi var en oppstart. Hver sprint var fylt med funksjoner, feilrettinger og kundeforespørsler. Å bygge en intern skjermbildebehandlingstjeneste var et fleremåneders prosjekt vi rett og slett ikke kunne rettferdiggjøre. Vi måtte levere produkt, ikke verktøy.

3. Manuelt arbeid som ikke skalerte

En stund prøvde vi en halvmanuell tilnærming: designeren opprettet maler, et skript behandlet dem i batch, og noen verifiserte og lastet opp manuelt. Men dette gikk stadig i stykker. Et skrift ville være feil, en ramme ville ikke stemme, teksten ville flyte over på tysk men se bra ut på engelsk. Hvert kanttilfelle ble en brannøvelse.

4. Pipelineintegrasjon var det manglende stykket

Vi ville ha en fullt automatisert flyt: kode pushes, pipeline kjører tester, skjermbilder fanges, skjermbilder behandles med riktig merkevare, og Fastlane laster dem opp til butikkene. Det manglende stykket var alltid behandlingstrinnet. Det fantes ingen tjeneste vi enkelt kunne kalle fra CI-pipelinen vår via et API.

Hvordan vi løste det

Denne frustrasjonen er nøyaktig grunnen til at Screenshots Live eksisterer. Ideen var enkel: en behandlingstjeneste som tar rå skjermbilder, bruker designerskapte maler med enhetsvinduer og merkevare, og returnerer butikk-klare bilder — alt via et enkelt API-kall som passer inn i enhver CI/CD-pipeline.

GitLab + Fastlane-integrasjonen

Slik så pipelinen vår ut etter integrering av Screenshots Live:

Bygge- og testfase: GitLab CI bygger appen for hver whitelabel-variant. UI-tester kjører og fanger rå skjermbilder med Fastlane snapshot / screengrab.
Skjermbildebehandlingsfase: Et enkelt skript går gjennom de fangede skjermbildene, kaller Screenshots Live med riktig mal-ID og merkevare-parametere for hver kunde, og laster ned de bearbeidede bildene.
Opplastingsfase: Fastlane deliver (iOS) og supply (Android) laster opp de bearbeidede skjermbildene til de respektive butikkene.

Hele flyten — fra kodepush til butikk-klare skjermbilder — ble fullt automatisert. Ingen designerinvolvering for rutineutgivelser. Ingen manuell QA av skjermbildeoppsett. Ingen brannøvelser når en kunde ba om en hotfix-release kl. 17:00 på en fredag.

Hva som endret seg

Tidsbesparelser

Det som brukte å ta designeren vår 2-3 dager per releasesyklus tar nå null menneskelig tid. Pipelinen tar seg av alt. For 20 apper som gir ut annenhver uke, er det omtrent 40-60 designerdager spart per år — tid designeren vår kunne bruke på faktisk produktdesign i stedet for repetitiv skjermbildemontering.

Konsistens

Hvert skjermbilde, for hver kunde, for hver enhetsstørrelse, følger nøyaktig samme mal. Ikke mer problemer som "iPhone 15 Pro Max-versjonen har teksten litt feilstilt". Malene er piksel-perfekte og brukes konsekvent hver gang.

Designeruavhengighet

Designeren vår kunne oppdatere maler når han ville — nye enhetsvinduer, oppdatert markedsføringstekst, sesongdesigner — uten å trenge involvering av utviklere. Han oppdaterte malen i den visuelle editoren, og neste pipelinekjøring hentet den automatisk.

Klientonboarding

Å legge til en ny whitelabel-klient gikk fra "planlegg 2 dager med designarbeid" til "lag en ny malvariant med merkevare-fargene og logoen deres". Pipelinen tok seg av resten.

Hvorfor vi gjør det tilgjengelig

Etter å ha brukt dette internt og sett hvor mye tid det sparte, innså vi at dette ikke var et problem unikt for oss. Enhver app-utvikler som publiserer til App Store eller Google Play håndterer skjermbildegenerering. Whitelabel-utviklere har det verst, men selv et enkelt-app-team med flerspråklig støtte møter det samme multiplikatorproblemet.

Så vi ryddet det opp, bygde et ordentlig API med dokumentasjon, la til en malredigerer som ikke-utviklere kan bruke, og åpnet det. Hvis du bruker timer på å manuelt lage App Store-skjermbilder, eller hvis pipelinen din har et gap mellom "fange skjermbilder" og "laste opp til butikken", fyller Screenshots Live det gapet.

Vi bygde det fordi vi trengte det. Vi deler det fordi vi vet at du også trenger det.