Нужно ли устанавливать Simulator на сборочную машину Xcode 27? Минимальная конфигурация 2026

Сборочная машина долго инициализируется, а диск заполняется компонентами, которые релизный pipeline не запускает.

Быстрое решение: если вы выполняете только компиляцию, Release Archive, подпись и загрузку, начните с Xcode без iOS Simulator Runtime; установите Runtime отдельно только для UI-тестов, Preview или проверки совместимости версий.

Кому нужен этот разбор

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

Если проект содержит Storyboard или XIB, вы сможете проверить границу между компиляцией интерфейса и запуском симулятора в Xcode 27. Если команде нужны Simulator, XCTest UI Tests или проверка нескольких версий iOS, здесь есть схема разделения публикационной и тестовой среды.

Важно: сведения о режиме Interface Builder относятся к Xcode 27 Beta. По состоянию на 5 сентября 2026 года Apple подтверждает этот режим в Beta Release Notes, но поведение RC и финального выпуска нельзя заранее считать неизменным. Перед обновлением окружения повторно сверяйте официальные заметки Apple.

Сначала разделите четыре компонента

Главная ошибка при проектировании сборочной машины — называть «симулятором» всё, что устанавливается вместе с Xcode. Для принятия решения нужно разделить компоненты:

• Xcode — среда разработки и набор инструментов сборки;
• платформенный SDK — файлы, необходимые для компиляции под целевую платформу;
• Simulator Runtime — операционная среда, в которой запускается iOS-приложение на виртуальном устройстве;
• симулируемое устройство — созданный профиль устройства, например виртуальный iPhone с выбранным Runtime.

Apple описывает установку дополнительных компонентов отдельно от общих системных требований Xcode. Поэтому наличие iOS-цели в проекте ещё не означает, что на сервере должен быть установлен каждый доступный Runtime. Проверяйте состав компонентов через официальные средства Xcode, а не копируйте конфигурацию рабочего Mac разработчика: [документация Apple по дополнительным компонентам Xcode](https://developer.apple.com/documentation/Xcode/downloading-and-installing-additional-xcode-components?changes=la_4_5_9&language=objc) разделяет установку платформ и симуляторных компонентов. <

Задача на сборочной машине	Нужен iOS Simulator Runtime	Что считать доказательством
Компиляция приложения и Release Archive	Нет, если скрипты не выбирают Simulator destination	Успешный Archive из реального проекта и проверка xcarchive
Подписывание и подготовка к загрузке	Нет	Корректная подпись и успешная проверка перед загрузкой
Storyboard/XIB в стандартном Interface Builder toolchain	Не обязательно	Archive с настоящими ресурсами интерфейса
Старая конфигурация Interface Builder в simulator-режиме	Да, если этот режим реально используется	Проверка IBC_COCOATOUCH_COMPILER_MODE и повторная сборка
XCTest на macOS	Нет	Запуск тестового action с macOS destination
XCTest на iOS Simulator	Да	Тестовый результат с выбранными Runtime и destination
XCTest UI Tests	Да	Сохранённый xcresult после запуска приложения в Simulator
SwiftUI Preview и интерактивная отладка	Да для полноценного запуска Preview	Рабочая тестовая среда с доступным симулятором
Проверка поведения на нескольких версиях iOS	Да	Отдельная матрица Runtime и отчёты по каждому сценарию

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

Первый шаг: зафиксируйте обязанности публикационного Mac

Для машины, которая только выпускает приложение, составьте список фактических действий:

1. получить исходный код;
2. установить зависимости;
3. выполнить обычную компиляцию;
4. создать Release Archive;
5. подписать приложение;
6. проверить архив;
7. подготовить пакет для загрузки;
8. передать его в App Store Connect.

Не добавляйте в список «запуск симулятора на всякий случай». Если workflow не вызывает simctl, не выбирает platform=iOS Simulator и не запускает тестовый action на виртуальном устройстве, Runtime не является автоматически необходимой частью Archive-процесса.

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

Отдельно проверьте пользовательские хуки. Даже если основной pipeline выполняет только Archive, дополнительные шаги могут:

• искать доступное симулируемое устройство;
• вызывать simctl для очистки состояния;
• запускать test, а не только archive;
• выбирать destination по шаблону;
• строить приложение для тестирования перед упаковкой;
• выполнять скрипт, рассчитанный на рабочую станцию с полным набором Runtime.

Успешный exit code одной команды не подтверждает, что вы проверили весь процесс публикации. Смотрите на сам архив, подпись и результат подготовки к загрузке. Общий порядок подготовки приложения к beta-тестированию и релизу описан в [руководстве Apple по распространению приложений](https://developer.apple.com/documentation/xcode/distributing-your-app-for-beta-testing-and-releases?changes=_7).

Второй шаг: проверьте UIKit-проект и Interface Builder

Проекты со Storyboard и XIB часто создают ложную тревогу: разработчик видит интерфейсные ресурсы и предполагает, что для их компиляции обязательно нужен iOS Simulator. В Xcode 27 Beta Apple указывает, что UIKit-документы по умолчанию обрабатываются новым Interface Builder toolchain. В пределах этой подтверждённой Beta-функции сама компиляция IB-документов не требует скачивания Simulator Runtime.

Но это не означает, что любое Storyboard/XIB-сборочное окружение можно очищать без проверки. Сначала найдите настройки проекта, цели и скриптов, которые могут переопределять стандартный режим. Особое внимание уделите параметру IBC_COCOATOUCH_COMPILER_MODE. Его наличие и допустимые значения проверяйте по Build Settings Reference от Apple.

Порядок проверки должен быть таким:

1. выберите реальный Scheme, используемый для релиза;
2. найдите настройки проекта и target, связанные с Interface Builder;
3. проверьте, не задаётся ли simulator-режим вручную;
4. найдите такие же параметры в xcconfig-файлах и CI-скриптах;
5. убедитесь, что в репозитории есть настоящие Storyboard/XIB, а не только пустой демонстрационный экран;
6. выполните чистый Archive без установленного Runtime;
7. проверьте наличие интерфейсных ресурсов в архиве;
8. только после этого закрепляйте минимальную конфигурацию.

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

Третий шаг: отделите Archive от тестового action

В Xcode термин «тесты» объединяет разные задачи. Для инфраструктуры это критичное различие:

• macOS-тесты могут выполняться без iOS Simulator;
• XCTest, запускаемый в iOS Simulator, требует совместимый Runtime;
• UI Tests требуют запуска приложения и взаимодействия с виртуальным устройством;
• build-for-testing может только подготовить продукты, а может быть частью цепочки, которая позднее запускается на Simulator;
• test-without-building зависит от destination, выбранного на этапе запуска;
• тестовый Plan может содержать цели, которые не видны в короткой команде CI.

Apple отдельно описывает запуск приложения на симулируемых и физических устройствах в [документации по запуску приложений](https://developer.apple.com/documentation/xcode/running-your-app-on-simulated-or-physical-devices). Из этого следует практическое правило: Runtime нужен не потому, что target называется iOS, а потому, что конкретный action должен загрузить и запустить iOS-бинарник в виртуальном окружении.

Для каждого Scheme и Test Plan запишите:

• action: build, archive, test или другой;
• destination;
• набор тестовых targets;
• необходимость запуска приложения;
• ожидаемый файл результата;
• путь восстановления при отсутствии Runtime.

Результат тестирования сохраняйте в xcresult. Он подтверждает, что тестовая задача действительно выполнялась, а не просто завершилась компиляция тестовых исходников. В [руководстве Apple по запуску тестов и интерпретации результатов](https://developer.apple.com/documentation/xcode/running-tests-and-interpreting-results?changes=_9) описаны результаты, которые нужно анализировать после запуска.

Не называйте pipeline «прошедшим iOS-тесты», если он только создал тестовые продукты. Это разные уровни проверки, и смешение терминов приводит к опасной экономии: команда удаляет Runtime, а затем обнаруживает проблему только перед релизом.

Четвёртый шаг: вынесите SwiftUI Preview и совместимость в отдельную среду

SwiftUI Preview, интерактивная отладка, проверка разных размеров экранов и регрессии на нескольких версиях iOS относятся к рабочей или тестовой среде, а не к минимальному публикационному Mac. Их задача — наблюдать поведение приложения, поэтому одной компиляции недостаточно.

Для такой команды разумно разделить два контура:

• публикационный — стабильный Xcode, SDK, сертификаты, профили и только компоненты, необходимые для Archive;
• тестовый — Simulator Runtime, созданные устройства, UI Tests, Preview и версии iOS, которые реально входят в матрицу проверки.

Это разделение уменьшает риск, что перед самым выпуском установка нового Runtime изменит состояние тестовой машины или потребует длительной повторной инициализации. При этом оно не означает, что тестовый Mac должен содержать все возможные версии iOS. Состав выбирайте по поддерживаемым сценариям и устанавливайте компоненты официальным способом.

Если проект проверяется на нескольких платформах и версиях, зафиксируйте соответствие между тестом и Runtime. Apple описывает установку приложения на нескольких Simulator-платформах и версиях в документации по множественным симуляторным окружениям. Не превращайте этот список в универсальное требование для каждой сборочной машины: для Release Archive он не нужен сам по себе.

Пятый шаг: установите границу для удалённого Mac

Удалённая машина особенно чувствительна к лишним компонентам. Вам нужно учитывать не только место на диске, но и операционные последствия:

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

Проверяйте конфигурацию в порядке риска, а не в порядке меню Xcode:

• [ ] Зафиксирован Scheme, который создаёт релизный Archive.
• [ ] Найдены все вызовы simctl, Simulator destination и тестовые хуки.
• [ ] Проверены Scheme, Test Plan и параметры xcodebuild.
• [ ] Проверен параметр IBC_COCOATOUCH_COMPILER_MODE.
• [ ] Archive выполнен на том же коммите, который предназначен к публикации.
• [ ] Архив содержит ожидаемые приложения, ресурсы Storyboard/XIB и подпись.
• [ ] Выполнена проверка перед загрузкой.
• [ ] Если тесты запускаются, сохранён соответствующий xcresult.
• [ ] Для каждого отсутствующего Runtime записан способ восстановления.
• [ ] Публикационная и симуляторная среды разделены, если тесты часто меняются.
• [ ] После холодного запуска Mac повторены ключевые команды.
• [ ] Документировано, какие задачи намеренно не выполняются на публикационной машине.

Такой список полезнее, чем проверка «Xcode открылся». Рабочий интерфейс не показывает, какие скрытые действия запустит CI после получения нового коммита.

Оцените три рабочих варианта

Для низкочастотных сборок можно устанавливать Runtime только перед тестовым циклом, если у команды есть время на подготовку и понятный способ очистки. Это экономит постоянные зависимости, но требует дисциплины: перед релизом нужно проверить, что компонент установлен и соответствует destination.

Для стабильного релизного контура лучше оставить минимальный Mac без Simulator Runtime. Такой вариант подходит, когда основная ответственность машины — Archive, подпись и загрузка, а тесты выполняются отдельно. Он не заменяет тестовую инфраструктуру и не даёт права утверждать, что UI-поведение проверено.

Для команды с частыми UI-тестами выгоднее разделить публикационный и тестовый Mac. Публикационная среда меняется редко, а тестовая получает Runtime и виртуальные устройства по плану. Это дороже по числу сред, зато снижает вероятность, что эксперимент с тестовой версией iOS сломает выпускной процесс.

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

FAQ: границы минимальной конфигурации

Можно ли создать Archive в Xcode 27 без установленного iOS Simulator?

Да, если задача ограничивается сборкой приложения, созданием Release Archive, кодовой подписью и подготовкой файла к загрузке. Перед удалением Runtime проверьте реальный Scheme, скрипты и параметры назначения. Команда xcodebuild должна пройти на чистом окружении, а результат нужно подтвердить проверкой xcarchive, подписи и этапа перед загрузкой, а не только кодом возврата процесса.

Нужен ли Simulator Runtime для проекта со Storyboard или XIB?

Не обязательно. В Xcode 27 Beta UIKit-документы по умолчанию используют Interface Builder toolchain, поэтому сама компиляция Storyboard или XIB не должна автоматически требовать iOS Simulator Runtime. Однако проект может явно задавать старый simulator-режим через IBC_COCOATOUCH_COMPILER_MODE. Это нужно проверить в Build Settings и подтвердить Archive с настоящими ресурсами интерфейса.

Какие компоненты Xcode нужны удалённой iOS-сборочной машине?

Минимальный набор определяется действиями CI: Xcode, нужные платформенные SDK, инструменты командной строки, сертификаты и профили подписи. Simulator Runtime нужен только заданиям, которые действительно запускают iOS-приложение в симуляторе. Список компонентов составляйте по Scheme, Test Plan и destination, а не по факту поддержки iOS в проекте.

Можно ли удалить Simulator, если сборка загружается только в TestFlight?

Обычно да, если перед загрузкой выполняются только Archive, проверка подписи и подготовка релизного пакета. Удаление Runtime нельзя считать безопасным до проверки скриптов: fastlane, тестовые actions и пользовательские хуки могут запускать simctl или выбирать симуляторный destination. После изменения окружения повторите полный процесс на том же коммите.

Какие задачи xcodebuild обязательно зависят от Simulator?

Зависимость появляется, когда xcodebuild должен запустить тестовый бинарник на iOS Simulator: это UI Tests, симуляторные XCTest, а также сценарии test-without-building с соответствующим destination. Простая компиляция, macOS-тесты и Archive сами по себе не доказывают необходимость Runtime. Для каждого Test Plan фиксируйте destination и сохраняйте xcresult как подтверждение выполнения.

Что выбрать перед арендой удалённого Mac

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

Для временной миграции, проверки Xcode 27 Beta или подготовки независимого CI-контурa аренда MACGPU позволяет сначала проверить реальный проект в минимальной конфигурации: начать с публикационного Mac без Simulator Runtime, а затем добавить отдельную тестовую среду, если Scheme действительно запускает Simulator или UI Tests. Это рациональнее, чем постоянно оплачивать компоненты и ресурсы, которые ваш pipeline не использует.

Перед началом аренды подготовьте короткий сценарий проверки: чистый Archive, Storyboard/XIB, подпись, проверка перед загрузкой и, при необходимости, отдельный тестовый запуск с xcresult. Если после такой проверки выяснится, что вам нужен постоянный тяжёлый тестовый контур, физический Mac или собственная инфраструктура могут быть выгоднее долгосрочной аренды. Но для краткого подтверждения совместимости и временного CI-цикла сначала выбирайте конфигурацию по фактическим действиям, а не по максимальной комплектации.

Последний раз сведения проверены 5 сентября 2026 года по системным требованиям Xcode и заметкам к Xcode 27 Beta. При выходе новой Beta, RC или финальной версии повторите минимальный Archive и отдельный запуск Simulator-тестов: именно эти два результата показывают, можно ли сохранить публикационную машину без Runtime.