iOS 27 CI: ещё нужен Simulator? Решение по узлам 2026

Не удаляйте Simulator со всех CI-узлов: в Xcode 27 часть UIKit-документов Interface Builder может собираться в toolchain-режиме без Simulator, но тесты с запуском приложения, UI-тесты и runtime-проверки по-прежнему требуют Simulator или физическое устройство. Практичное решение для iOS 27 CI — разделить облегчённый узел сборки и полноценный узел тестирования, а затем подтвердить схему двойным прогоном на одном коммите.

Эта статья предназначена для трёх групп:

• инженеров сборки, которым нужны компиляция, статический анализ и выпуск артефактов без лишней зависимости от runtime;
• команд тестирования, поддерживающих XCTest, UI-автоматизацию и несколько версий iOS;
• DevOps- и platform-инженеров, меняющих пул удалённых Mac, кеши и процедуру восстановления.

Последнее обновление: 8 сентября 2026 года. Данные сверены с примечаниями к выпуску Xcode 27, документацией Apple по тестированию и справочником настроек сборки.

[ SECTION_01 ] Матрица решений для iOS 27 CI

В Xcode 27 Beta 6 Apple подтвердила две важные границы. Xcode 27 запускается только на Mac с Apple Silicon, а документы UIKit Interface Builder по умолчанию могут компилироваться в toolchain-режиме без предварительной загрузки Simulator runtime. Это зафиксировано в официальных примечаниях к выпуску Xcode 27.

Из этого не следует, что Simulator стал необязательным для всего конвейера. Компиляция ресурсов — это один слой. Запуск приложения и проверка поведения iOS — другой. В iOS 27 CI необходимо проверять фактический destination, Test Host, SDK и команду, которая запускает тесты.

Тип задачи	Нужен Simulator runtime	Рекомендуемый узел	Что подтвердить
Swift-компиляция и статический анализ	Обычно нет, если проект не запускает приложение	Облегчённый	Логи компилятора и отсутствие обращения к destination
Компиляция Storyboard и XIB	Не всегда	Облегчённый после проверки	Режим Interface Builder, артефакты и предупреждения
Обычная сборка приложения	Зависит от ресурсов и build settings	Облегчённый или переходный	Реальный вызов инструментов и итоговый продукт
XCTest с Test Host	Да	Полный тестовый	Запуск приложения-хоста и выбранный destination
UI-тесты XCTest	Да	Полный тестовый	Simulator, устройство, Test Plan и результат выполнения
Интеграционная проверка системных API	Да или физическое устройство	Полный тестовый	Версия iOS и воспроизводимость поведения

Ключевой критерий — не наличие слова «Unit» в названии target. Важнее то, запускает ли задача процесс приложения и зависит ли от поведения платформы.

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

[ SECTION_02 ] Команда сборки и Interface Builder

Toolchain-режим UIKit

Для новых или совместимых документов UIKit Interface Builder Xcode 27 предлагает toolchain-модель компиляции. Её смысл — обработать Storyboard и XIB на уровне инструментов сборки, не поднимая полноценную среду выполнения приложения. Это особенно важно для узлов, где требуется только подготовить архив или другой артефакт.

Однако проект может отличаться от демонстрационного сценария. Риск создают:

• старые Storyboard и XIB с нестандартными ресурсами;
• пользовательские build settings;
• прямой вызов ibtool в скрипте;
• отдельные target, для которых настройки отличаются;
• плагины и скрипты, не входящие в стандартную схему Xcode.

Название режима следует проверять в конфигурации цели, а не угадывать по результату сборки. В справочнике Build Settings нужно найти настройку IBC_COCOATOUCH_COMPILER_MODE и сопоставить её со значением, реально применённым в CI. Если проект использует собственные .xcconfig, проверку проводят для каждой конфигурации: Debug, Release и специальных CI-вариантов.

Проверка Storyboard и XIB

Для существующего проекта безопаснее использовать последовательную проверку:

1. Зафиксировать коммит, Xcode 27 Beta 6, SDK и выбранную конфигурацию.
2. Запустить чистую сборку без тестов.
3. Сохранить полный лог, включая вызовы компилятора Interface Builder.
4. Проверить сгенерированные ресурсы в архиве или каталоге продуктов.
5. Сравнить предупреждения и ошибки с прежним узлом.
6. Отдельно открыть приложение тестовым контуром и проверить экраны, созданные из Storyboard и XIB.

Пункт 6 нельзя заменять успешным завершением xcodebuild. Сборка подтверждает создание продукта. Она не подтверждает корректное создание экземпляров, подключение outlet и поведение переходов во время выполнения.

Если документ не проходит toolchain-режим, команда не должна молча возвращать Simulator на весь пул. Лучше записать точное условие: конкретный target, ресурс, конфигурацию или скрипт. После этого возможны три варианта — исправить проект, направить только этот target на полный узел или временно включить simulator-режим с понятной процедурой возврата.

Инструкции по изменению параметров цели приведены в документации Apple о настройке Build Settings для target. Это полезнее, чем менять параметры непосредственно в скрипте CI: настройки проекта остаются видимыми для следующего инженера.

[ SECTION_03 ] Тестовые нагрузки и граница runtime

Чистые Swift-тесты

Чистый тест бизнес-логики может не нуждаться в запуске iOS-приложения. Но такое решение нельзя принимать по имени тестового target. В проекте могут присутствовать импорты платформенных фреймворков, Test Host или настройки destination, которые переводят тест в другой режим.

Проверка должна включать:

• значение Test Host;
• схему запуска и destination;
• SDK, с которым компилируется тест;
• наличие .xctest и связанных продуктов;
• фактическую команду xcodebuild;
• результат выполнения, а не только этап компиляции.

Если тест действительно изолирован от приложения и платформенного поведения, его можно направить на облегчённый удалённый Mac. Но перенос следует считать условным: изменение схемы или добавление одной зависимости может вернуть runtime-требование.

Тесты с приложением-хостом

Тест, который загружает приложение-хост, проверяет уже не только Swift-код. В этом случае CI должен запустить процесс приложения, загрузить нужные фреймворки и выбрать destination. Такой контур сохраняют на узле с Simulator или физическим устройством.

Документация Apple по запуску тестов и интерпретации результатов помогает отделить подготовку тестового продукта от его выполнения. Для диагностики полезно хранить .xcresult, лог команды и параметры destination. Без них команда видит только зелёный или красный статус и не может доказать, где возникла зависимость от runtime.

UI-тесты

XCTest UI Tests должны запустить приложение и взаимодействовать с его интерфейсом. Поэтому toolchain-режим Interface Builder не заменяет Simulator. Он может упростить подготовку ресурсов, но не создаёт виртуальное устройство, процесс iOS и пользовательский сеанс.

Для UI-контура нужно зафиксировать:

• Test Plan;
• целевое устройство;
• версию iOS;
• способ создания или выбора Simulator;
• .xcresult;
• скриншоты, видео или диагностические вложения при ошибке;
• поведение после перезапуска узла.

Документация Apple по Test Plan полезна при разделении наборов. Быстрые smoke-тесты можно запускать чаще, а расширенный набор — на отдельном полном узле. При параллельном выполнении следует наблюдать за созданием клонов Simulator, конкуренцией за CPU, память, хранилище и процессами очистки. Универсальный объём ресурсов без измерений объявлять нельзя.

[ SECTION_04 ] Топология удалённых Mac-узлов

Для команды, которая использует удалённый Mac, важна не только возможность подключиться по SSH или VNC. Нужно заранее определить, какой узел хранит runtime, где создаются кеши, кто очищает временные устройства и как восстанавливается рабочее состояние после перезапуска.

Топология	На каком контуре работает	Преимущество	Риск	Оценка
Один полный узел	Сборка и все тесты вместе	Простая маршрутизация	Все задачи конкурируют за Simulator и кеши	3/5
Два пула	Облегчённая сборка отдельно, тесты отдельно	Ясная граница зависимостей	Нужны передача артефактов и согласование Xcode	5/5
Временная миграция	Новый узел только для проверяемых задач	Минимальный риск для production	Дольше поддерживать два сценария	4/5
Полное удаление runtime	Только задачи без запуска приложения	Минимум обслуживания	UI и интеграционные проверки ломаются	1/5

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

Разделение build-for-testing и test-without-building

Apple описывает связку build-for-testing и test-without-building в технической заметке TN2339. Идея проста: один этап создаёт тестовые продукты и сведения для запуска, другой использует их на тестовом destination.

Для CI это даёт следующий маршрут:

1. На облегчённом узле выполнить обычную сборку и проверить, не вызывается ли Simulator.
2. На том же или отдельном узле выполнить build-for-testing.
3. Передать полученные продукты и настройки тестов в тестовый пул.
4. Выполнить test-without-building на подготовленном Simulator.
5. Сопоставить SDK, схему, архитектуру и destination.
6. Сохранить результат тестирования и диагностические файлы.

Передача артефактов не должна быть формальной. Если тестовый узел использует другой Xcode, SDK или набор платформ, зелёный статус перестаёт быть сопоставимым с исходной сборкой. В документации Apple также доступен справочник командной строки Xcode, который следует использовать при составлении воспроизводимых команд.

Три условия выбора

Оставить один полный узел разумно, если:

• проект часто выполняет UI-тесты;
• Storyboard и XIB ещё не прошли проверку toolchain-режима;
• команда не умеет быстро восстанавливать Simulator после сбоя.

Разделить пул на сборочный и тестовый следует, если:

• чистая сборка стабильно завершается без обращения к runtime;
• тестовые продукты можно передать между узлами;
• Test Plan явно определяет тестовый destination;
• есть отдельная процедура очистки и восстановления.

Отложить миграцию нужно, если:

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

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

[ SECTION_05 ] FAQ для команды CI

Xcode 27 и сборка без Simulator

Да, часть проектов можно собирать без загрузки Simulator runtime. Это относится к подтверждённому Apple toolchain-режиму для UIKit Interface Builder. Но обычная сборка не равна тестированию. Если следующий этап запускает приложение или проверяет поведение iOS, ему потребуется полноценный runtime-контур.

Задачи, которым нужен Simulator runtime

В обязательную группу входят UI-тесты, тесты с Test Host и интеграционные проверки, зависящие от поведения iOS. Также runtime нужен для проверки выбранной версии системы и конфигурации устройства. Чистый статический анализ и изолированная логика могут быть вынесены, но только после проверки destination и фактических команд.

Совместимость Storyboard и XIB

Новый режим не даёт автоматической гарантии для старого проекта. Проверяются не только Storyboard и XIB, но также xcconfig, target-настройки, скрипты и прямые вызовы инструментов. После успешной сборки нужно запустить приложение и сравнить результат интерфейса. При несовместимости фиксируется конкретная точка отката.

Распределение удалённых Mac

Сборочный пул обслуживает задачи, которым не нужно запускать приложение. Тестовый пул хранит Simulator runtime и принимает test-without-building. Между ними передаются проверенные артефакты. Такой подход позволяет не загружать runtime на каждый узел, но требует одинаковых версий Xcode, SDK и согласованных процедур восстановления.

[ SECTION_06 ] Двойная приёмка перед изменением production

Релизный ответственный должен выбрать настоящий проект, а не минимальный пример. В выборку включают хотя бы один Storyboard или XIB, приложение-хост, UI-тест и обычный тест логики. Один и тот же коммит прогоняется на старом полном узле и на кандидате без Simulator.

Порядок приёмки:

1. Зафиксировать Xcode 27 Beta 6, SDK, схему и параметры среды.
2. Очистить или явно описать состояние кешей.
3. Выполнить обычную сборку и build-for-testing.
4. Проверить, обращался ли процесс к Simulator runtime.
5. Выполнить test-without-building на полном тестовом узле.
6. Сравнить .xcresult, предупреждения, артефакты и UI-диагностику.
7. Перезапустить узлы и повторить критический маршрут.
8. Проверить восстановление после прерванной задачи.
9. Только после этого изменить маршрутизацию production.

Официальный статус Xcode 27 и iOS 27 на указанную дату остаётся Beta-статусом. Поведение финальной версии, исправления известных проблем и окончательный диапазон поддержки нельзя заранее объявлять установленным фактом. Поэтому рекомендации из медиа или прогнозы даты релиза не должны использоваться как основание для удаления runtime. Для публикационного контура полезно отдельно проверить требования App Store Connect к загрузке сборок.

[ SECTION_07 ] Итог для владельца CI-платформы

В iOS 27 CI Simulator можно убрать не «из проекта», а только из тех задач, которые доказанно не запускают приложение и не зависят от runtime. Xcode 27 расширяет пространство для облегчённого toolchain-сборочного узла, но не отменяет Simulator для XCTest с хостом, UI-автоматизации и платформенных интеграционных проверок.

Полное удаление Simulator с текущего узла может выглядеть дешевле и проще, но создаёт три реальные проблемы: UI-тесты теряют рабочую среду, скрытые зависимости обнаруживаются только после миграции, а восстановление production-конвейера становится ручным. Кроме того, единый пул смешивает компиляцию и тяжёлые тестовые процессы, поэтому сбой или очистка Simulator затрагивает несвязанные сборки.

Более устойчивый вариант — сначала скопировать реальный проект на отдельный удалённый Mac, выполнить чистую сборку и полный тестовый маршрут, а затем разделить узлы по доказанным зависимостям. Если нужен временный сборочный или тестовый контур без покупки отдельного Mac, аренда Mac через NOVAKVM позволяет выбрать срок под этап проверки и не менять production до завершения двойной приёмки. Доступные варианты аренды Mac стоит рассматривать после фиксации того, нужен ли узлу только toolchain или полный Simulator runtime.