Автоматизация скриншотов App Store: 2026 fastlane snapshot на удалённом Mac // Блог NOVAKVM

Автоматизацию скриншотов App Store стоит выбирать только тогда, когда приложение нужно регулярно показывать на нескольких языках, устройствах или экранах; для небольшой разовой подборки ручная съёмка быстрее. На удалённом Mac сначала зафиксируйте тестовые данные, локаль и Simulator, затем запускайте fastlane snapshot последовательно и лишь после стабильного результата добавляйте параллельность и загрузку.

Эта инструкция предназначена для:

независимых разработчиков, выпускающих несколько локализованных версий приложения;
Windows- и Linux-разработчиков без постоянно доступного Mac, которым нужны Xcode UI Tests и iOS Simulator;
небольших команд, включающих генерацию изображений в процесс релиза.

[ SECTION_01 ] Сначала оцените матрицу скриншотов, а не устанавливайте инструменты

Автоматизация скриншотов App Store начинается не с команды установки fastlane. Сначала нужно описать матрицу, которая действительно должна быть воспроизведена.

Для каждого изображения зафиксируйте четыре свойства:

экран или состояние приложения;
язык и регион;
класс устройства;
частоту обновления после изменения интерфейса.

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

При этом в рабочем процессе нужно разделять четыре операции:

захват исходного экрана в Simulator;
добавление рамки, фона и маркетингового текста;
проверку названий и порядка файлов;
загрузку ассетов в App Store Connect.

fastlane snapshot отвечает прежде всего за управляемый захват изображений через XCTest. Он не заменяет проверку содержимого и не делает любую картинку автоматически подходящей для публикации. За оформление отвечает отдельный сценарий, например frameit, а за отправку ассетов — отдельный процесс загрузки. Это разделение описано в официальной документации fastlane по снимкам экранов и в документации fastlane frameit.

Когда ручная работа ещё рациональна

Ручной способ подходит, если:

набор экранов небольшой;
используется один язык;
приложение редко меняет интерфейс;
изображения нужно получить один раз перед публикацией;
разработчик может лично проверить каждое состояние.

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

Оценивать нужно не число файлов само по себе, а число повторяемых комбинаций: экран × язык × устройство. Если каждая комбинация создаётся заново после изменения интерфейса, сценарий XCTest обычно даёт больший контроль, чем ручная съёмка.

[ SECTION_02 ] Первый рабочий контур: один язык и один Simulator

До многоязычной генерации нужен минимальный воспроизводимый контур. Его задача — доказать, что приложение открывает нужный экран, тест нажимает правильные элементы, а файлы сохраняются в ожидаемом порядке.

Шаг 1. Создайте отдельную цель UI-тестов

В Xcode добавьте самостоятельный UI Test Target, например с условным именем <APP_NAME>UITests. Не смешивайте сценарий снимков с длинными регрессионными тестами. Снимкам нужны короткие действия и предсказуемое состояние.

В тесте задайте понятные идентификаторы доступности для элементов:

let app = XCUIApplication()
app.launchArguments = ["-uiTestMode", "-screenshotData", "screenshots-en"]
app.launch()

app.buttons["primary_action"].tap()
XCTAssertTrue(app.staticTexts["screen_title"].waitForExistence(timeout: 10))

Здесь <APP_NAME>, ключи и названия элементов являются примерами. В реальном проекте их нужно заменить собственными значениями. Для поиска элементов используйте документацию Apple по XCUIElementQuery, а не координаты экрана. Координатные нажатия ломаются при смене размера, ориентации и языка.

Шаг 2. Подготовьте общую Scheme

Scheme должна быть доступна в репозитории и пригодна для запуска из командной строки. Включите нужную цель приложения, UI Test Target и конфигурацию сборки для снимков.

Проверьте:

Scheme отмечена как Shared;
тестовая цель собирается без ручного выбора в Xcode;
Bundle ID приложения не перепутан с идентификатором тестов;
нужная версия приложения устанавливается в Simulator;
тест не зависит от открытого локального окна Xcode.

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

Шаг 3. Изолируйте вход и данные

Как fastlane snapshot фиксирует вход в аккаунт и тестовые данные? Не через случайное сохранённое состояние Simulator, а через явный сценарий запуска.

Подготовьте один из вариантов:

локальную тестовую базу, создаваемую при флаге <SCREENSHOT_DATA>;
тестовую учётную запись <TEST_ACCOUNT>;
заранее выпущенный токен только для тестового окружения;
управляемые launch arguments для состояния подписки, пустого списка и заполненного профиля.

Тестовые данные должны включать все состояния, которые видит пользователь на скриншотах. Отдельно контролируйте:

авторизован ли пользователь;
есть ли активная подписка;
включён ли нужный функциональный флаг;
загружены ли изображения и списки;
отображается ли ошибка сети.

Нельзя полагаться на историю предыдущего запуска. Сбой сети или старый cookie-файл может незаметно изменить изображение. Для релизных снимков лучше запускать приложение с очищенным состоянием и повторно создавать фиксированный набор данных.

Шаг 4. Подключите конфигурацию snapshot

В конфигурации укажите Scheme, Bundle ID, язык, устройства и каталог вывода. Имена устройств должны совпадать с доступными Simulator Runtime на конкретном Mac. Не переносите конфигурацию на другой узел без проверки: список установленных Runtime, версия Xcode и поддерживаемые цели могут отличаться.

Условный файл Snapfile может выглядеть так:

scheme("<APP_SCHEME>")
devices([
  "<IPHONE_DEVICE>"
])
languages([
  "en-US"
])
output_directory("./fastlane/screenshots")
clear_previous_screenshots(true)

Это шаблон. <APP_SCHEME> и <IPHONE_DEVICE> нужно заменить на значения проекта. Набор параметров и правила их обработки сверяйте с официальным описанием действия snapshot.

Запускайте сценарий сначала для одной локали и одного устройства. Успешным результатом считается не зелёный статус команды, а одновременно:

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

Apple также описывает, как интерпретировать результаты тестов, в руководстве по запуску тестов Xcode. Отчёт нужно сохранять вместе с артефактами, а не проверять только итоговую строку терминала.

[ SECTION_03 ] Языки и локали: отделяйте перевод от состояния приложения

Переключение языка Simulator само по себе не создаёт качественную локализацию. Язык интерфейса, региональные форматы и серверные данные — разные уровни конфигурации.

Для каждой локали определите:

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

Например, английский интерфейс с региональными настройками другой страны может показать иной формат даты или цены. Если команда меняет только системный язык, а тестовый сервер возвращает данные по умолчанию, снимок будет формально локализованным, но содержательно неверным.

Шаг 5. Сделайте запуск локали повторяемым

Удобно хранить локали в конфигурации fastlane и передавать параметры приложению через launchArguments или переменные окружения. Для каждого запуска задавайте условные значения:

<LOCALE> = fr-FR
<REGION> = FR
<DATA_SET> = subscription-active
<FEATURE_FLAGS> = screenshots

Не вставляйте в репозиторий реальные пароли, токены или персональные данные. Для доступа к тестовому API используйте ограниченную учётную запись и секреты среды выполнения.

После генерации сравнивайте одинаковый узел сценария между языками. Проверяйте не только перевод:

не обрезан ли заголовок;
не исчезла ли кнопка;
не наложился ли текст на изображение;
завершилась ли загрузка;
не появился ли fallback на другой язык;
совпадает ли состояние экрана.

Как fastlane snapshot автоматически создаёт многоязычные изображения для App Store? Он повторяет XCTest UI Tests для заданных языков и устройств, но корректность перевода, данных и визуального состояния всё равно должна быть проверена отдельно. Автоматический запуск не заменяет лингвистическую и визуальную приёмку.

Важно: исходный снимок и маркетинговая композиция — разные артефакты. Сначала сохраняйте чистый экран приложения. Рамку, фон и рекламный текст добавляйте после проверки исходного изображения, иначе ошибка в UI будет замаскирована оформлением.

[ SECTION_04 ] Устройства и размеры: сокращайте матрицу осознанно

Не следует механически запускать тест на каждом доступном Simulator. Сначала определите, какие классы устройств действительно требуются для страницы приложения в App Store Connect. Актуальные размеры и допустимые отображаемые цели нужно сверять с таблицей спецификаций скриншотов Apple.

Apple указывает конкретные размеры изображений для поддерживаемых целей. Например, в требованиях встречаются варианты iPhone 6,9″ с разрешением 1 320 × 2 868 пикселей, iPhone 6,5″ — 1 284 × 2 778 пикселей, а для iPhone 5,5″ — 1 242 × 2 208 пикселей. Эти значения нельзя переносить в конфигурацию «по памяти»: Apple может менять список отображаемых целей и правила приёма, поэтому ссылка на текущую справку должна оставаться частью процедуры проверки.

Шаг 6. Разделите комбинации устройств

Сформируйте отдельные группы:

вертикальные iPhone;
горизонтальные iPhone, если приложение использует альбомный режим;
iPad с собственной раскладкой;
специальные экраны, где меняется навигация или плотность элементов.

App Store Connect может использовать масштабирование для части совместимых размеров. Это удобно, когда интерфейс одинаково читается после уменьшения. Собственные изображения нужны, если меняются композиция, расположение элементов, количество колонок или маркетинговый текст.

После запуска проверяйте не только расширение файла. Важны:

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

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

[ SECTION_05 ] Сравнение способов: ручной захват, snapshot и удалённый Mac

Решение зависит не от моды на автоматизацию, а от повторяемости задачи. В таблице ниже сравниваются роли инструментов, а не рекламные свойства конкретного сервиса.

Вариант	Подходит для	Сильная сторона	Ограничение	Решение
Ручной захват	Один язык, небольшой набор экранов, редкое обновление	Быстрая разовая проверка	Ошибки при повторении локалей и устройств	Выбирать для единичного релиза
`fastlane snapshot` на локальном Mac	Повторяемая матрица и регулярные изменения	Один XCTest-сценарий создаёт согласованные исходники	Требуются Xcode, Simulator Runtime и подготовленная конфигурация	Выбирать для постоянной автоматизации
`fastlane snapshot` на удалённом Mac	Нет постоянно доступного Mac или нужен узел для ночных задач	Доступ к macOS без покупки отдельного компьютера	Нужно контролировать сессию, диск, связь и возврат артефактов	Выбирать при повторных удалённых запусках
Снимки плюс `frameit`	Нужны готовые маркетинговые изображения	Отделяет UI от оформления	Рамка не исправляет ошибку интерфейса	Использовать после приёмки исходников
Автоматическая загрузка	Матрица уже проверена и каталог стабилен	Сокращает ручную передачу файлов	Ошибка может массово отправить неверные ассеты	Включать последним этапом

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

[ SECTION_06 ] Удалённый Mac: сначала стабильный сеанс, потом параллельность

Можно ли пакетно создавать скриншоты iOS без локального Mac? Да, если доступен удалённый Mac с совместимыми Xcode и Simulator Runtime, а разработчик может получить тестовые артефакты. Но удалённый доступ не отменяет требований XCTest: приложение, тесты и Simulator должны запускаться на macOS, а не на Windows или Linux.

Удалённый запуск отличается от локального не самим сценарием, а операционными рисками:

разрыв VNC-сеанса не должен останавливать команду;
блокировка пользовательской сессии может повлиять на графические процессы;
временные файлы Simulator занимают место;
соединение не должно быть единственным способом получить логи;
ошибочный запуск должен перезапускать только проблемную комбинацию.

Шаг 7. Проверьте среду до первого ночного запуска

Перед запуском зафиксируйте:

версию macOS и Xcode;
установленные Simulator Runtime;
Scheme и Bundle ID;
каталог исходников и каталог артефактов;
переменные локали;
способ передачи секретов;
команду очистки предыдущего результата.

Снимки не требуют постоянного наблюдения через удалённый рабочий стол. Запускайте процесс через SSH или другой доступный командный интерфейс, а VNC используйте для диагностики. Это уменьшает зависимость от открытого окна, но не устраняет необходимость в активной пользовательской сессии, если конкретный графический тест этого требует.

Шаг 8. Начните с последовательного выполнения

Параллельный запуск нескольких iOS Simulator легко создаёт конфликт за CPU, оперативную память, дисковый ввод-вывод и графический интерфейс. Универсальное утверждение о скорости здесь было бы неверным: результат зависит от модели Mac, версии Xcode, Runtime, размера приложения и сценария UI Tests.

Сначала выполните все выбранные локали и устройства последовательно. Соберите:

длительность каждого запуска;
размер логов и изображений;
этап, на котором возникла ошибка;
состояние Simulator после сбоя;
возможность повторить только неудачную комбинацию.

Только после этого включайте ограниченную параллельность. Если два Simulator приводят к нестабильному запуску, вернитесь к последовательному режиму. Для скриншотов предсказуемость важнее номинального ускорения.

Шаг 9. Добавьте восстановление после сбоя

Надёжный сценарий должен сохранять результат каждого законченного набора, а не только общий статус pipeline. Используйте структуру вроде:

artifacts/
  <LOCALE>/
    <DEVICE>/
      screenshots/
      test-results/
      logs/

Названия <LOCALE> и <DEVICE> заменяются фактическими значениями. После ошибки:

сохраните лог и результат XCTest;
определите локаль и устройство;
очистите только повреждённый Simulator или его состояние;
повторите одну комбинацию;
замените артефакт после успешной проверки;
не загружайте весь пакет автоматически, пока не завершён контроль.

Это особенно важно для удалённого Mac: при разрыве соединения разработчик должен получить файлы через заранее определённый каталог или артефактное хранилище, а не искать их вручную на рабочем столе.

[ SECTION_07 ] Финальная приёмка перед App Store Connect

Автоматизация заканчивается не после создания PNG. Перед загрузкой проверьте весь путь от чистого экрана до обработанного ассета.

Шаг 10. Разделите оформление и отправку

fastlane snapshot сохраняет исходные кадры. frameit может добавить устройство, фон и текстовую композицию. Инструмент загрузки или App Store Connect API отправляет подготовленные файлы. Эти этапы лучше выполнять разными командами.

Такой порядок даёт возможность:

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

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

Чек-лист загрузки

Перед отправкой в App Store Connect подтвердите:

каталог соответствует нужному языку;
порядок файлов отражает порядок экранов;
размеры соответствуют текущим требованиям Apple;
нет тестовых логинов, отладочных надписей и системных окон;
нет пустого состояния вместо наполненного;
изображения относятся к текущей версии приложения;
статус обработки проверен после загрузки;
запись о запуске содержит Scheme, локаль, устройство и дату;
неудачные комбинации не попали в финальный пакет.

Для секретов App Store Connect используйте отдельную конфигурацию с минимально необходимыми правами. Ключ не следует помещать в Snapfile, логи терминала или открытый репозиторий.

[ SECTION_08 ] Итоговый выбор для независимого разработчика

Если проект имеет один язык, несколько редко меняющихся экранов и разовый релиз, ручная съёмка сохраняет преимущество: настройка сценария может занять больше времени, чем сама операция. Если же приложение выходит в нескольких локалях, требует вариантов для iPhone и iPad и регулярно меняет интерфейс, fastlane snapshot превращает повторение в проверяемый процесс.

Удалённый Mac особенно полезен как временный или постоянный исполнитель Xcode UI Tests, когда локального Mac нет либо его не хочется держать занятым. Но сначала должен работать последовательный минимальный сценарий. Параллельность и автоматическую загрузку нужно добавлять только после того, как сохранение файлов, восстановление после ошибки и визуальная приёмка доказали стабильность.

В сравнении с локальным Windows/Linux-сценарием остаются три реальных недостатка: Xcode и Simulator нельзя запустить нативно, приходится поддерживать обходной CI-контур, а передача артефактов добавляет ещё одну операционную точку контроля. Покупка отдельного Mac устраняет часть сетевых рисков, но требует заранее оплаченного оборудования и обслуживания даже тогда, когда снимки нужны только во время релиза. Если задача повторяется, но не оправдывает постоянную покупку, удалённый Mac для iOS-задач от NOVAKVM позволяет вынести Xcode и Simulator на отдельный узел и оплачивать среду под фактический график работы.

Перед выбором стоит определить режим: краткая аренда для одного релиза, регулярный доступ для локализованных обновлений или постоянный узел для ночных сценариев. После этого полезно проверить доступные варианты аренды Mac mini и отдельно оценить, как будут организованы подключение, хранение логов и возврат скриншотов. Такой подход сохраняет нейтральную экономику решения: NOVAKVM имеет смысл там, где удалённая среда сокращает повторяющиеся операции, но не заменяет необходимость правильно спроектировать XCTest-сценарий.

Автоматизация скриншотов App Store: 2026 fastlane snapshot на удалённом Mac