Skip to content
All Posts
Blog·March 4, 2026

Why I Built Screenshots Live: A Whitelabel Developer's Story

Managing 20 whitelabel apps with different stores and brandings taught me one thing: automating App Store screenshots shouldn't be this painful. Here's why I built Screenshots Live.

The Problem: 20 Apps, 20 Brands, Hundreds of Screenshots

A few years ago, I was working as a developer at a startup where we built a whitelabel mobile app. One codebase, but 20 different clients — each with their own branding, colors, logos, and App Store listings. Every single one needed its own set of polished App Store and Google Play screenshots.

If you've ever published an app, you know the drill: Apple wants screenshots for every device size (6.7", 6.5", 5.5", iPad Pro, iPad...), Google Play wants its own set, and if you support multiple languages, multiply everything again. Now multiply that by 20 clients.

We're talking about thousands of screenshots that needed to be generated, framed in device mockups, branded with the right colors, and uploaded — every single release cycle.

What We Had: Automated Screenshots in the Pipeline

The raw screenshots themselves weren't the problem. We had that part figured out. Our UI tests, running in our GitLab CI pipeline, would launch each app variant, navigate through the key screens, and capture screenshots automatically. Fastlane's snapshot (iOS) and screengrab (Android) handled the heavy lifting there.

So we had hundreds of raw PNG files landing in our pipeline artifacts after every build. Great. But raw screenshots don't go on the App Store. They need to be processed — placed inside device frames, given a background that matches the client's brand, overlaid with marketing copy, and exported at the exact pixel dimensions each store requires.

The Pain Points

1. The Designer Bottleneck

Our designer was talented, but asking them to manually update Figma files for 20 brands every release was absurd. They'd spend days just swapping screenshots and adjusting colors. And if a client changed their branding mid-cycle? Start over.

2. No Time to Build Internal Tooling

We were a startup. Every sprint was packed with features, bug fixes, and client requests. Building an internal screenshot processing service — with a template system, device frame rendering, text overlay, and store-specific export — was a months-long project we simply couldn't justify. We needed to ship product, not tooling.

3. Manual Work That Didn't Scale

For a while, we tried a semi-manual approach: the designer created templates, a script would batch-process them, and someone would manually verify and upload. But this broke constantly. A font would be wrong, a frame wouldn't align, the text would overflow in German but look fine in English. Every edge case became a fire drill.

4. Pipeline Integration Was the Missing Piece

We wanted a fully automated flow: code gets pushed, pipeline runs tests, screenshots are captured, screenshots get processed with the right branding, and Fastlane uploads them to the stores. The missing piece was always the processing step. There was no service we could just call from our CI pipeline with an API.

How We Solved It

This frustration is exactly why Screenshots Live exists. The idea was simple: a processing service that takes raw screenshots, applies designer-created templates with device frames and branding, and returns store-ready images — all via a simple API call that fits into any CI/CD pipeline.

The GitLab + Fastlane Integration

Here's what our pipeline looked like after integrating Screenshots Live:

  1. Build & Test Stage: GitLab CI builds the app for each whitelabel variant. UI tests run and capture raw screenshots using Fastlane snapshot / screengrab.
  2. Screenshot Processing Stage: A simple script loops through the captured screenshots, calls the Screenshots Live with the right template ID and branding parameters for each client, and downloads the processed images.
  3. Upload Stage: Fastlane deliver (iOS) and supply (Android) upload the processed screenshots to the respective stores.

The entire flow — from code push to store-ready screenshots — became fully automated. No designer involvement for routine releases. No manual QA of screenshot layouts. No fire drills when a client requested a hotfix release at 5 PM on a Friday.

What Changed

Time Savings

What used to take our designer 2-3 days per release cycle now takes zero human time. The pipeline handles everything. For 20 apps releasing bi-weekly, that's roughly 40-60 designer-days saved per year — time our designer could spend on actual product design instead of repetitive screenshot assembly.

Consistency

Every screenshot, for every client, for every device size, follows the exact same template. No more "the iPhone 15 Pro Max version has the text slightly misaligned" issues. The templates are pixel-perfect, and they're applied consistently every single time.

Designer Independence

Our designer could update templates whenever they wanted — new device frames, updated marketing copy, seasonal designs — without needing developer involvement. They'd update the template in the visual editor, and the next pipeline run would pick it up automatically.

Client Onboarding

Adding a new whitelabel client went from "schedule 2 days of design work" to "create a new template variant with their brand colors and logo." The pipeline took care of the rest.

Why We're Making It Available

After using this internally and seeing how much time it saved, we realized this wasn't a problem unique to us. Every app developer who ships to the App Store or Google Play deals with screenshot generation. Whitelabel developers have it worst, but even a single-app team with multi-language support faces the same multiplier problem.

So we cleaned it up, built a proper API with documentation, added a template editor that non-developers can use, and opened it up. If you're spending hours manually creating App Store screenshots, or if your pipeline has a gap between "capture screenshots" and "upload to store," Screenshots Live fills that gap.

We built it because we needed it. We're sharing it because we know you need it too.