В документации Apple явно разделены два класса целей запуска — simulated devices и physical devices: это не одно и то же окружение и не взаимозаменяемые результаты тестирования (руководство Apple по запуску приложения).
Симптом: удалённый Mac собирает проект, но iOS Simulator не завершает запуск.
Самое быстрое решение: проверяйте не только SSH и Xcode, а связку macOS + Xcode + Simulator Runtime + графическая сессия; затем прогоняйте реальный проект до отключения и перезагрузки узла.
Облачный сервер macOS действительно может запускать iOS Simulator, если это настоящий Mac с совместимой системой, установленным нужным Runtime и рабочей пользовательской графической сессией. Одного успешного xcodebuild недостаточно: SSH может подтверждать доступ к инструментам сборки, но не готовность Simulator к отображению интерфейса и взаимодействию.
Эта проверка предназначена для:
- разработчиков iOS без локального Mac, которым нужны сборка, отладка интерфейса и базовые функциональные тесты;
- инженеров автоматизации и DevOps, проверяющих работу Simulator без постоянного подключения к рабочему столу;
- владельцев общей платформы, которым необходимо разделить графические задачи, CLI-тесты, кэш и ресурсы между командами.
SECTION 01Что именно нужно доказать до аренды
Проверка должна разделять три разных вывода:
- Xcode можно установить и открыть.
- Проект можно собрать командой или из интерфейса Xcode.
- Целевой Simulator можно запустить, разблокировать, использовать для теста и восстановить после сбоя или перезагрузки.
Эти утверждения не следуют автоматически одно из другого. Например, совместимая версия Xcode может запускаться, но нужный iOS Simulator Runtime ещё не установлен. Или Runtime присутствует, однако процесс не получает полноценную графическую сессию. В результате xcodebuild завершается успешно, а устройство остаётся в состоянии Booting, показывает чёрный экран или недоступно для UI-теста.
Перед выбором узла зафиксируйте:
- версию macOS;
- установленную версию Xcode;
- требуемый iOS Simulator Runtime;
- модель целевого симулируемого устройства;
- способ графического подключения;
- пользователя, от имени которого будут запускаться Xcode и тесты;
- ожидаемый сценарий: интерактивная разработка, автоматизация или оба режима.
Матрица системных требований Apple рассматривает совместимость через несколько отдельных параметров — macOS, SDK и deployment target. Поэтому сверяйте именно официальную таблицу требований, а не название процессора или общую фразу «поддерживается Xcode» (системные требования Xcode).
Приёмочный лист перед оформлением аренды
Отмечайте каждый пункт только после фактической проверки. Если любой обязательный пункт остаётся неподтверждённым, не переводите узел в категорию «готов для iOS Simulator».
- [ ] Это настоящий удалённый Mac, а не только эмулируемая или виртуализированная среда с неопределённым доступом к macOS-инструментам.
- [ ] Версия macOS входит в поддерживаемый диапазон выбранного Xcode.
- [ ] Версия Xcode соответствует SDK и deployment target вашего проекта.
- [ ] Нужный iOS Simulator Runtime установлен и отображается среди доступных платформ.
- [ ] Графический вход через VNC, веб-консоль или другой предоставленный способ действительно открывает рабочий стол.
- [ ] Simulator запускается в этой графической сессии, а не только появляется в выводе
simctl. - [ ] Виртуальное устройство завершает загрузку, отображает интерфейс и принимает базовые действия.
- [ ] Реальное приложение устанавливается, запускается и выдаёт доступные для анализа логи.
- [ ] Одиночный автоматизированный тест проходит без ручного открытия Xcode.
- [ ] После разрыва подключения и перезагрузки узла инструменты и тестовый сценарий восстанавливаются в пределах вашей процедуры.
- [ ] Ограничения Simulator зафиксированы: физические сенсоры, аппаратная производительность и финальная проверка на iPhone не включены в этот результат.
Решение принимайте по условиям:
- Если все пункты, относящиеся к вашему сценарию, отмечены, то узел можно использовать после проверки реального проекта.
- Если отмечены только пункты сборки и CLI-тестов, то среда подходит для ограниченной автоматизации, но не доказана для интерактивного Simulator.
- Если не подтверждены Runtime или графическая сессия, то отложите аренду либо запросите другой узел.
- Если не пройдена проверка после перезагрузки, то не называйте среду полностью автономной.
- Если проект требует физического устройства, то переходите к тестированию на iPhone независимо от результата этого листа.
SECTION 02Первая графическая сессия и подготовка Xcode
Первый вход выполняйте через предоставленный удалённый графический способ — VNC, веб-консоль или другой рабочий интерфейс. SSH оставьте для диагностики и повторяемых команд. Это важно, потому что первоначальный запуск Xcode может потребовать подтверждения лицензии, подготовки компонентов или действий в интерфейсе.
Последовательность проверки:
- Войдите в графическую сессию под тем пользователем, от имени которого будет выполняться разработка или CI-задача.
- Запустите Xcode вручную и дождитесь завершения первого запуска.
- Подтвердите лицензионные и системные запросы, если они появляются.
- Откройте настройки компонентов и проверьте наличие нужного Simulator Runtime.
- Запишите, какие действия потребовали человека.
- Закройте и повторно откройте Xcode, чтобы исключить случайный успех только первого запуска.
- После этого выполните базовую проверку через командную строку.
Apple отдельно описывает установку дополнительных компонентов Xcode. Наличие приложения в каталоге не означает, что все платформы и Runtime уже загружены (инструкция Apple по дополнительным компонентам Xcode).
В графической сессии проверьте также блокировку экрана, разрешение удалённого управления, состояние пользователя и поведение после разрыва подключения. Если окно Simulator исчезает вместе с сеансом, это не обязательно ошибка iOS-инструментов: возможно, удалённый сервис завершает пользовательскую сессию вместо её сохранения.
Если доступен только SSH
Через SSH вы можете проверить расположение инструментов и получить список устройств:
xcode-select -p
xcodebuild -version
xcrun simctl list devices
Эти команды показывают состояние инструментов и зарегистрированных устройств, но их вывод не доказывает, что удалённый рабочий стол способен показать и принять действия в Simulator. Apple предоставляет отдельный справочник командных инструментов Xcode, включая CLI-интерфейсы для рабочих процессов разработки (справочник Xcode Command Line Tools).
Если xcrun simctl list devices возвращает устройство, а графическое окно не появляется, не переустанавливайте проект вслепую. Сначала проверьте:
- действительно ли вход выполнен в тот же пользовательский профиль;
- запущена ли графическая сессия;
- не установлен ли Runtime частично;
- хватает ли свободного диска;
- не остался ли зависший процесс Simulator;
- не меняется ли переменная окружения разработчика между SSH и GUI.
SECTION 03Запуск устройства и проверка состояния
После подготовки создайте или выберите устройство с тем Runtime, который соответствует проекту. Управлять симулируемыми устройствами можно из Xcode Device and Simulators и через simctl; Apple описывает оба направления управления в документации Device Hub (управление симулируемыми и физическими устройствами).
Порядок приёмки должен быть наблюдаемым:
- Запустите целевое устройство из Xcode или командой
simctl. - Дождитесь перехода устройства в рабочее состояние.
- Убедитесь, что окно Simulator отображается в удалённой графической сессии.
- Выполните разблокировку и базовое взаимодействие с интерфейсом.
- Запустите заранее выбранное тестовое приложение.
- Проверьте установку, запуск и остановку приложения.
- Сопоставьте состояние окна с результатом команды
simctl.
Проходным результатом является не строка «Booted» сама по себе, а согласованная цепочка: устройство запущено, интерфейс виден, ввод обрабатывается, приложение устанавливается и логи доступны. Если CLI сообщает о рабочем состоянии, а окно чёрное, это два разных результата, которые нужно расследовать отдельно.
Разбор типовых отказов
Чёрный экран. Сначала проверьте графический канал, пользователя и процесс Simulator. Если другие приложения в той же сессии также не отображаются, причина, вероятно, находится не в проекте.
Бесконечный Booting. Проверьте выбранный Runtime, состояние устройства, свободное дисковое пространство и журналы. Не создавайте много новых устройств до понимания причины: это может усложнить диагностику и увеличить расход диска.
Целевой Runtime отсутствует. Сверьте deployment target проекта с установленными платформами. Затем проверьте, разрешена ли загрузка дополнительного компонента и не требует ли она повторного подтверждения в графическом интерфейсе.
Устройство есть в списке, но тест не подключается. Убедитесь, что автоматизация использует тот же набор инструментов, пользователя и переменные окружения, что и ручной запуск.
SECTION 04Реальный проект вместо демонстрационной сборки
Пустой проект может подтвердить только базовую работоспособность Xcode. Для решения о пригодности узла используйте проект, который содержит ваши зависимости, схемы, тестовые данные, подписи и необходимые скрипты. Apple описывает создание проекта и запуск приложения как последовательность, где выбирается цель запуска и затем выполняется сборка с установкой на выбранное устройство (документация Apple по проекту Xcode).
Проверяйте цепочку в таком порядке:
- получение исходников из репозитория;
- установка зависимостей;
- выбор схемы и конфигурации;
- сборка;
- установка приложения на Simulator;
- запуск нужного сценария;
- чтение консольных логов;
- остановка и повторный запуск;
- сохранение артефактов и отчётов.
Отдельно разделите операции, которые выполняются через CLI, и операции, для которых требуется Xcode или видимый Simulator. Это даст ответ на вопрос о роли удалённого Mac:
- для сборки и части тестов может быть достаточно SSH;
- для визуальной отладки нужен устойчивый удалённый рабочий стол;
- для UI-автоматизации нужно проверить, сохраняется ли пользовательская сессия;
- для подписи, профилей и некоторых первоначальных настроек могут потребоваться ручные действия.
Запуск тестов оценивайте по отчёту, логам и фактическому поведению приложения, а не только по коду завершения команды. В официальной документации Apple описаны запуск тестов и интерпретация результатов, включая работу с результатами тестирования в Xcode (руководство по запуску тестов).
SECTION 05Автоматизация, изоляция и работа без оператора
После ручной проверки перенесите тот же сценарий в автоматизацию. Не начинайте с параллельного запуска: сначала добейтесь повторяемого одиночного прогона, в котором можно сохранить логи, снимок состояния и код ошибки.
Минимальный автоматизированный цикл должен включать:
- проверку выбранного Xcode и Runtime;
- создание или выбор устройства;
- запуск Simulator;
- ожидание готовности устройства по проверяемому состоянию;
- сборку и установку приложения;
- выполнение тестов;
- сохранение результатов;
- остановку устройства и очистку временных данных.
Не вводите универсальный тайм-аут или предполагаемое число параллельных задач без собственной проверки. Время запуска, допустимая нагрузка и способность узла обслуживать несколько Simulator зависят от конкретной системы, Runtime, проекта, диска и удалённого рабочего стола. Такие значения нельзя выдавать за общую гарантию Apple.
Для общего узла заранее разделите:
- пользователей и их права;
- каталоги DerivedData и кэшей;
- симулируемые устройства;
- временные файлы тестов;
- логи и артефакты;
- графические сеансы.
Если два задания используют один Simulator, они могут влиять друг на друга через состояние приложения, данные пользователя, разрешения и фоновые процессы. Если два задания используют общий каталог кэша или общий диск, отказ одного процесса может проявиться как ошибка другого. Поэтому критерий готовности — не только «тест запустился», но и возможность объяснить, какие ресурсы принадлежат каждой задаче.
Руководство Apple по тестированию охватывает общую модель Xcode Testing и запуск тестов, однако конкретную устойчивость удалённого узла всё равно нужно проверять в вашем CI-сценарии (официальный раздел Xcode Testing).
SECTION 06Отключение, смена сессии и перезагрузка
Последняя проверка начинается после успешного теста. Отключите удалённый рабочий стол, не закрывая весь пользовательский сеанс, затем подключитесь снова. После этого повторите запуск приложения и хотя бы один автоматизированный сценарий.
Затем проверьте более жёсткие условия:
- завершение SSH-сеанса во время длительного теста;
- повторный графический вход;
- выход пользователя из системы;
- перезагрузка узла;
- повторное подключение после загрузки;
- доступность Xcode, Runtime и симулируемого устройства;
- сохранность логов и отчётов.
Не считайте восстановление доказанным, если после перезагрузки вы вручную открыли Xcode, приняли запрос и заново создали устройство. Такой результат означает, что цепочка требует ручного обслуживания. Для интерактивной разработки это может быть допустимо, для полностью автономного CI — уже нет.
Итоговая классификация после приёмки
Примите решение по результатам, а не по обещанию совместимости:
- Если графическая сессия работает, Simulator запускается, приложение устанавливается, отладка проходит и восстановление после перезагрузки подтверждено, то узел подходит для интерактивной разработки и автоматизации.
- Если CLI-сборка и тесты устойчивы, но окно Simulator недоступно или графическая сессия не сохраняется, то узел подходит только для автоматизированных задач, которые не требуют визуального контроля.
- Если ручной запуск проходит, но после отключения или перезагрузки Runtime, устройство либо тестовый процесс не восстанавливаются, то узел требует изменения сценария, прав, сессии или конфигурации.
- Если реальный проект не собирается, нужный Runtime нельзя установить или устройство стабильно остаётся в
Booting, то узел не подходит для этой задачи. - Если тест требует физического сенсора, аппаратной производительности или поведения настоящего телефона, то переходите к проверке на физическом устройстве независимо от результата Simulator.
Если вам нужен временный узел для такой проверки, можно начать с подходящего периода аренды MACNOX и прогнать именно свой проект, а не демонстрационный пример. Варианты подключения и доступные направления следует сверять на странице выбора удалённого Mac, а условия оплаты и длительность периода — на странице тарифов MACNOX. Перед оплатой за длительный период зафиксируйте целевой Runtime и сценарий восстановления.
SECTION 07Где заканчивается iOS Simulator
Удалённый Mac с iOS Simulator не превращается в удалённый iPhone. Simulator полезен для проверки интерфейса, навигации, части системных API, базовых сценариев и автоматизированных тестов, но результаты не равны испытаниям на физическом устройстве.
Apple разделяет запуск на симулируемых и физических устройствах именно потому, что у них различаются аппаратная среда и способ проверки (официальное руководство Apple по simulated и physical devices). Поэтому перед выпуском отдельно проверяйте:
- поведение камеры и других физических сенсоров;
- Bluetooth и взаимодействие с внешними аксессуарами;
- push-уведомления в условиях, близких к production;
- энергопотребление и нагрев;
- работу на реальных размерах и характеристиках экрана;
- производительность и память на целевой модели;
- поведение при прерывании связи, звонке и фоновых ограничениях;
- финальную подпись, установку и публикацию.
Если требуется физический интерфейс, реальный сенсор или измерение производительности устройства, удалённый Simulator не является полной заменой iPhone. Он закрывает часть цикла разработки, но не отменяет отдельный этап испытаний на реальном оборудовании.
При сравнении с текущим вариантом — Linux-сервером, локальным Windows-компьютером или виртуальной macOS — учитывайте не рекламное название, а стоимость ограничений: там может отсутствовать нативная связка Xcode и Simulator Runtime, графическая сессия может быть недоступна для UI-тестов, а восстановление после перезагрузки потребует ручных действий. Настоящий удалённый Mac от MACNOX удобнее именно тогда, когда вам нужно быстро получить рабочую macOS-среду, проверить собственный проект и не покупать отдельный компьютер ради временного или переменного объёма задач.
Если после полной приёмки вам нужна стабильная долгосрочная нагрузка, постоянный физический доступ к устройству или испытания на настоящем iPhone, разумнее рассмотреть собственное оборудование либо отдельный контур с физическими устройствами. Если же задача ограничена разработкой, базовыми тестами и периодическими CI-прогонами, сначала подтвердите четыре условия — Runtime, графическая сессия, реальный проект и восстановление — на коротком периоде аренды MACNOX, а затем выбирайте дальнейший срок по результатам журнала проверки.