Problemet: 20 appar, 20 varumärken, hundratals skärmdumpar

För några år sedan jobbade jag som utvecklare på en startup där vi byggde en whitelabel-mobilapp. En kodbas, men 20 olika kunder — var och en med sin egen varumärkesidentitet, färger, logotyper och App Store-listningar. Var och en behövde sin egen uppsättning polerade App Store- och Google Play-skärmdumpar.

Om du någonsin har publicerat en app känner du till rutinen: Apple vill ha skärmdumpar för varje enhetsstorlek (6.7", 6.5", 5.5", iPad Pro, iPad...), Google Play vill ha sin egen uppsättning, och om du stödjer flera språk multiplicerar du allt igen. Multiplicera nu det med 20 kunder.

Vi pratar om tusentals skärmdumpar som behövde genereras, inramade i enhetsmockups, märkta med rätt färger och uppladdade — varje releasecykel.

Vad vi hade: automatiserade skärmdumpar i pipelinen

De råa skärmdumparna i sig var inte problemet. Det hade vi löst. Våra UI-tester, som körde i vår GitLab CI-pipeline, startade varje appvariant, navigerade genom nyckelskärmarna och tog skärmdumpar automatiskt. Fastlanes snapshot (iOS) och screengrab (Android) skötte det tunga arbetet.

Så vi hade hundratals råa PNG-filer som landade i våra pipeline-artefakter efter varje bygge. Bra. Men råa skärmdumpar hamnar inte i App Store. De behöver bearbetas — placeras inuti enhetsramar, ges en bakgrund som matchar kundens varumärke, läggas med marknadsföringstext och exporteras i de exakta pixeldimensioner varje butik kräver.

Smärtpunkterna

1. Designerflaskhalsen

Vår designer var talangfull, men att be honom manuellt uppdatera Figma-filer för 20 varumärken vid varje release var absurt. Han tillbringade dagar med att bara byta ut skärmdumpar och justera färger. Och om en kund ändrade sin varumärkesidentitet mitt i cykeln? Börja om.

2. Ingen tid att bygga interna verktyg

Vi var en startup. Varje sprint var fullpackad med funktioner, buggfixar och kundförfrågningar. Att bygga en intern skärmdumpsbearbetningstjänst — med ett mallsystem, enhetsramsrendering, textöverlagring och butiksspecifik export — var ett månaders projekt vi helt enkelt inte kunde rättfärdiga. Vi behövde leverera produkt, inte verktyg.

3. Manuellt arbete som inte skalade

Ett tag försökte vi med ett halvmanuellt tillvägagångssätt: designern skapade mallar, ett skript bearbetade dem i batch och någon verifierade och laddade upp manuellt. Men det gick sönder hela tiden. Ett typsnitt skulle vara fel, en ram skulle inte passa, texten svämmar över på tyska men ser bra ut på engelska. Varje kantfall blev en brandövning.

4. Pipelineintegration var det saknade pusselbiten

Vi ville ha ett helt automatiserat flöde: kod pushas, pipeline kör tester, skärmdumpar fångas, skärmdumpar bearbetas med rätt varumärkesprofil och Fastlane laddar upp dem till butikerna. Det saknade pusselbiten var alltid bearbetningssteget. Det fanns ingen tjänst vi enkelt kunde anropa från vår CI-pipeline med ett API.

Hur vi löste det

Den här frustrationen är exakt varför Screenshots Live existerar. Idén var enkel: en bearbetningstjänst som tar råa skärmdumpar, tillämpar designerskapade mallar med enhetsramar och varumärkesprofil, och returnerar butiksklara bilder — allt via ett enkelt API-anrop som passar in i vilken CI/CD-pipeline som helst.

GitLab + Fastlane-integrationen

Så här såg vår pipeline ut efter integrering av Screenshots Live:

Bygge- och testfas: GitLab CI bygger appen för varje whitelabel-variant. UI-tester körs och fångar råa skärmdumpar med Fastlane snapshot / screengrab.
Skärmdumpsbearbetningsfas: Ett enkelt skript loopar igenom de fångade skärmdumparna, anropar Screenshots Live med rätt mall-ID och varumärkesparametrar för varje kund och laddar ner de bearbetade bilderna.
Uppladdningsfas: Fastlane deliver (iOS) och supply (Android) laddar upp de bearbetade skärmdumparna till respektive butiker.

Hela flödet — från kodpush till butiksklara skärmdumpar — blev helt automatiserat. Ingen designerinblandning för rutinreleaser. Ingen manuell QA av skärmdumpslayouter. Inga brandövningar när en kund bad om en hotfix-release kl. 17:00 på en fredag.

Vad som förändrades

Tidsbesparingar

Det som brukade ta vår designer 2-3 dagar per releasecykel tar nu noll mänsklig tid. Pipelinen hanterar allt. För 20 appar som releasar varannan vecka är det ungefär 40-60 designerdagar sparade per år — tid vår designer kunde lägga på faktisk produktdesign istället för repetitiv skärmdumpsmontering.

Konsekvens

Varje skärmdump, för varje kund, för varje enhetsstorlek, följer exakt samma mall. Inga fler problem som "iPhone 15 Pro Max-versionen har texten lite feljusterad". Mallarna är pixelperfekta och tillämpas konsekvent varje gång.

Designeroberoende

Vår designer kunde uppdatera mallar när han ville — nya enhetsramar, uppdaterad marknadsföringstext, säsongsdesigner — utan att behöva involvera utvecklare. Han uppdaterade mallen i den visuella editorn och nästa pipelinekörning hämtade den automatiskt.

Klientonboarding

Att lägga till en ny whitelabel-klient gick från "planera 2 dagars designarbete" till "skapa en ny mallvariant med deras varumärkesfärger och logotyp". Pipelinen skötte resten.

Varför vi gör det tillgängligt

Efter att ha använt det internt och sett hur mycket tid det sparade insåg vi att detta inte var ett problem unikt för oss. Varje apputvecklare som publicerar till App Store eller Google Play hanterar skärmdumpsgenering. Whitelabel-utvecklare har det värst, men även ett enkel-app-team med flerspråkigt stöd möter samma multiplikatorproblem.

Så vi städade upp det, byggde ett ordentligt API med dokumentation, lade till en malleditor som icke-utvecklare kan använda och öppnade upp det. Om du spenderar timmar på att manuellt skapa App Store-skärmdumpar, eller om din pipeline har ett gap mellan "fånga skärmdumpar" och "ladda upp till butiken", fyller Screenshots Live det gapet.

Vi byggde det för att vi behövde det. Vi delar det för att vi vet att du behöver det också.