2026: короткий цикл iOS — XCTest и параллельные симуляторы: один узел «в полную параллель» против двух посуточных cloud Mac runner с разнесением очереди — память, диск и ROI (FAQ)

В коротком цикле iOS-разработки 2026 года самый дорогой дефект — не «упал один тест», а хвост очереди: когда команда жмёт merge, а CI всё ещё гоняет UI-набор на нескольких симуляторах. XCTest умеет распараллеливать классы и таргеты, но каждый поднятый Simulator — это отдельный процесс с графикой, кэшем и пиками RAM. Отсюда два рабочих режима: один мощный Mac, где вы «забиваете» узел параллельными джобами, или два посуточных облачных runner'а, которые делят очередь по типам тестов (например, быстрые модульные на одном, тяжёлые UI — на другом). Оба варианта законны; выбор определяется бюджетом, допустимым уровнем флакинесса и тем, насколько вы готовы администрировать два образа. Полезный контекст по посуточной модели и управляемому CI — в материале App Center в 2026: окно миграции для короткого цикла — управляемый CI или посуточный cloud Mac runner?

Один узел «в полную параллель» против двух посуточных runner

Один крупный Apple Silicon Mac с достаточной унифицированной памятью даёт минимальную операционную сложность: один образ Xcode, один набор ключей, один кэш DerivedData. Вы поднимаете xcodebuild test с несколькими destination и параллельным планом — и wall time падает, пока не упрётесь в RAM или в дисковый I/O при установке билдов на симуляторы. Два посуточных облачных Mac runner'а дороже по фактуре, но проще удерживать стабильный SLO: на «лёгком» узле крутятся быстрые проверки PR, на «тяжёлом» — ночные UI и скриншотные сценарии; очереди не конкурируют за одну и ту же память. Регистрацию runner'ов, сеть и минимальные токены удобно сверить по чеклисту: Короткий цикл CI в 2026: всплеск сборок и новый облачный Mac — регистрация Runner, сеть и минимальные токены за 30–60 минут (чеклист и FAQ). На практике полезно фиксировать не только «сколько симуляторов вписалось», но и p95 длительности install/boot: если при добавлении воркера этот хвост растёт быстрее, чем падает общий wall time, параллелизм уже контрпродуктивен.

# Разнесите тяжёлые UI в отдельный job/scheme, а не в один «комбайн»
xcodebuild test \
  -scheme YourApp \
  -destination 'platform=iOS Simulator,name=iPhone 16' \
  -destination 'platform=iOS Simulator,name=iPhone 16 Pro' \
  -parallel-testing-enabled YES

Память, диск и эпизодические сбои под нагрузкой

Параллельные симуляторы увеличивают не только CPU, но и давление на APFS: установка приложения, сброс данных среды, логи XCTest и артефакты скриншотов быстро съедают inode и пропускную способность, если агент не чистит DerivedData между прогонами. Память — второй источник флаков: при свопе таймауты сетевых фикстур и анимаций UI начинают выглядеть как «нестабильные тесты». На одном перегруженном узле это проявляется чаще, чем при разнесении на два runner'а с меньшим числом одновременных симуляторов на каждый. Держите отдельный бюджет диска под кэш симуляторов и ротацию снимков среды; для ночных прогонов полезнее предсказуемый «холодный» старт с очисткой, чем накопившийся мусор, который маскируется под регрессию.

Матрица ROI: когда окупается второй посуточный cloud Mac

ROI считайте не только как «цена минуты CI», но как стоимость прерванного merge и повторного прогона всей матрицы. Ниже — упрощённая таблица для переговоров с финансами и security.

Короткий FAQ

Стоит ли гнать все симуляторы на одном Mac M4? — Если медиана времени зелёного прогона падает, а доля ретраев без изменений кода растёт, вы уже на плато; либо снижайте параллелизм, либо добавляйте второй узел.

Как доказать ROI второго runner'а за одну неделю? — Сравните p95 времени ожидания в очереди и число «пустых» ретраев до/после разнесения; одной недели достаточно для грубого порядка величин.

Что мониторить в первую очередь? — Свободная RAM, latency диска на этапах install/boot симулятора, размер логов и артефактов; CPU часто ведёт себя «красиво», пока память уже на пределе.