Проблема: 20 приложений, 20 брендов, сотни скриншотов

Несколько лет назад я работал разработчиком в стартапе, где мы создавали whitelabel-мобильное приложение. Одна кодовая база, но 20 разных клиентов — каждый со своим брендингом, цветами, логотипами и листингами в App Store. Каждому нужен был собственный набор отполированных скриншотов для App Store и Google Play.

Если вы когда-либо публиковали приложение, вы знаете эту рутину: Apple хочет скриншоты для каждого размера устройства (6.7", 6.5", 5.5", iPad Pro, iPad...), Google Play хочет свой набор, и если вы поддерживаете несколько языков, умножьте всё снова. Теперь умножьте это на 20 клиентов.

Мы говорим о тысячах скриншотов, которые нужно было генерировать, обрамлять в макеты устройств, брендировать правильными цветами и загружать — при каждом релизном цикле.

Что у нас было: автоматизированные скриншоты в pipeline

Сами сырые скриншоты не были проблемой. С этим мы разобрались. Наши UI-тесты, запущенные в нашем GitLab CI pipeline, запускали каждый вариант приложения, проходили по ключевым экранам и автоматически делали скриншоты. snapshot от Fastlane (iOS) и screengrab (Android) делали тяжёлую работу.

Итак, у нас были сотни сырых PNG-файлов, которые попадали в артефакты pipeline после каждого билда. Отлично. Но сырые скриншоты не идут в App Store. Их нужно обрабатывать — помещать в рамки устройств, давать фон, соответствующий бренду клиента, накладывать маркетинговый текст и экспортировать в точных пиксельных размерах, требуемых каждым магазином.

Болевые точки

1. Узкое горлышко дизайнера

Наш дизайнер был талантлив, но просить его вручную обновлять Figma-файлы для 20 брендов при каждом релизе было абсурдно. Он тратил дни просто на замену скриншотов и корректировку цветов. А если клиент менял брендинг в середине цикла? Начинать заново.

2. Не было времени строить внутренние инструменты

Мы были стартапом. Каждый спринт был забит фичами, фиксами и запросами клиентов. Строить внутренний сервис обработки скриншотов — с системой шаблонов, рендерингом рамок устройств, наложением текста и экспортом под каждый магазин — было проектом на несколько месяцев, который мы просто не могли оправдать. Нам нужно было поставлять продукт, а не инструменты.

3. Ручная работа, которая не масштабировалась

Какое-то время мы пробовали полуручной подход: дизайнер создавал шаблоны, скрипт обрабатывал их пакетно, а кто-то вручную проверял и загружал. Но это постоянно ломалось. Шрифт был неправильным, рамка не выравнивалась, текст переполнялся на немецком, но выглядел нормально на английском. Каждый крайний случай становился пожаром.

4. Интеграция с pipeline была недостающим звеном

Мы хотели полностью автоматизированный поток: код пушится, pipeline запускает тесты, скриншоты захватываются, скриншоты обрабатываются с нужным брендингом, и Fastlane загружает их в магазины. Недостающим звеном всегда был шаг обработки. Не было сервиса, который можно было просто вызвать из нашего CI-pipeline через API.

Как мы решили проблему

Именно из этого разочарования и появился Screenshots Live. Идея была простой: сервис обработки, который принимает сырые скриншоты, применяет созданные дизайнерами шаблоны с рамками устройств и брендингом, и возвращает готовые для магазинов изображения — всё через простой вызов API, который вписывается в любой CI/CD-pipeline.

Интеграция GitLab + Fastlane

Вот как выглядел наш pipeline после интеграции Screenshots Live:

Этап сборки и тестирования: GitLab CI собирает приложение для каждого whitelabel-варианта. UI-тесты запускаются и захватывают сырые скриншоты с помощью Fastlane snapshot / screengrab.
Этап обработки скриншотов: Простой скрипт обходит захваченные скриншоты, вызывает Screenshots Live с нужным ID шаблона и параметрами брендинга для каждого клиента, и загружает обработанные изображения.
Этап загрузки: Fastlane deliver (iOS) и supply (Android) загружают обработанные скриншоты в соответствующие магазины.

Весь поток — от пуша кода до готовых для магазина скриншотов — стал полностью автоматизированным. Никакого участия дизайнера в рутинных релизах. Никакой ручной проверки макетов скриншотов. Никаких пожаров, когда клиент просит хотфикс-релиз в пятницу в 17:00.

Что изменилось

Экономия времени

То, что раньше занимало у нашего дизайнера 2-3 дня за релизный цикл, теперь занимает ноль человеческого времени. Pipeline берёт на себя всё. Для 20 приложений, выходящих раз в две недели, это примерно 40-60 дней дизайнера, сэкономленных за год — время, которое наш дизайнер мог потратить на реальное проектирование продукта, а не на повторяющуюся сборку скриншотов.

Единообразие

Каждый скриншот, для каждого клиента, для каждого размера устройства, следует точно одному шаблону. Больше никаких проблем вроде «в версии для iPhone 15 Pro Max текст немного сдвинут». Шаблоны пиксельно точны и применяются единообразно каждый раз.

Независимость дизайнера

Наш дизайнер мог обновлять шаблоны когда захочет — новые рамки устройств, обновлённые маркетинговые тексты, сезонные дизайны — без участия разработчиков. Он обновлял шаблон в визуальном редакторе, и следующий запуск pipeline автоматически подхватывал его.

Онбординг клиентов

Добавление нового whitelabel-клиента перешло с «запланируй 2 дня дизайнерской работы» на «создай новый вариант шаблона с их цветами и логотипом». Pipeline брал на себя остальное.

Почему мы делаем это доступным

Используя это внутренне и видя, сколько времени это экономило, мы поняли, что это не уникальная для нас проблема. Каждый разработчик приложений, публикующий в App Store или Google Play, сталкивается с генерацией скриншотов. Whitelabel-разработчикам тяжелее всего, но даже команда с одним приложением и поддержкой нескольких языков сталкивается с той же проблемой умножения.

Поэтому мы привели это в порядок, создали нормальный API с документацией, добавили редактор шаблонов, который могут использовать не-разработчики, и открыли доступ. Если вы тратите часы на ручное создание скриншотов App Store, или если в вашем pipeline есть пробел между «захватить скриншоты» и «загрузить в магазин», Screenshots Live заполняет этот пробел.

Мы создали это, потому что нам это было нужно. Мы делимся этим, потому что знаем — вам это тоже нужно.