Ошибка загрузки iOS Simulator в Xcode 26.6: исправление на удалённом Mac в 2026 году

Наличие SDK не доказывает, что установлен соответствующий iOS Simulator runtime. Xcode может успешно компилировать проект, потому что SDK находится внутри приложения, но simctl не сможет создать или запустить виртуальное устройство без отдельного runtime. Apple описывает загрузку дополнительных компонентов как самостоятельную операцию через настройки Xcode или командные инструменты в документации по компонентам Xcode.

Проверьте три независимых признака:

xcode-select -p
xcodebuild -version
xcrun simctl list runtimes

Затем проверьте устройства:

xcrun simctl list devices

Интерпретируйте результат так:

• проект не компилируется — сначала проверяйте выбранный Xcode, SDK и зависимости;
• проект компилируется, но simctl list runtimes не показывает нужную платформу — отсутствует или не зарегистрирован runtime;
• runtime отображается, но устройства имеют состояние Unavailable или не запускаются — проблема перешла в слой CoreSimulator;
• устройство запускается, но тестовый процесс не стартует — ищите ошибку проекта, подписи, тестового раннера или самого теста.

Остановитесь после определения слоя. Не удаляйте Xcode, пока не сохранены выводы этих команд и журнал загрузки. Иначе вы потеряете исходные признаки и усложните сравнение с исправным узлом.

На удалённом Mac часто одновременно находятся несколько версий Xcode. Графическая оболочка может быть открыта из одного каталога, а терминал — использовать другой Developer Directory. В таком состоянии команда загрузки обращается не к той установке, которую вы проверяете в интерфейсе.

Сначала получите фактические пути:

xcode-select -p
xcrun --find simctl
xcrun --find xcodebuild
xcodebuild -version

Сравните результат с приложением Xcode 26.6, открытым через графический интерфейс. Если путь не совпадает, временно укажите нужное приложение:

sudo xcode-select --switch "/Applications/<Xcode-26.6>.app/Contents/Developer"

После этого повторите проверку:

xcodebuild -version
xcrun simctl list runtimes

Не меняйте глобальный выбор на общем CI-узле без согласования. Такая команда влияет на процессы, которые запускаются без явного DEVELOPER_DIR. Для отдельной сессии безопаснее использовать переменную:

export DEVELOPER_DIR="/Applications/<Xcode-26.6>.app/Contents/Developer"

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

Контрольный список:

• [ ] xcode-select -p указывает на Xcode 26.6;
• [ ] xcrun --find simctl относится к той же установке;
• [ ] xcodebuild -version показывает ожидаемую версию;
• [ ] первичный запуск Xcode завершён под нужной учётной записью;
• [ ] повторная команда xcrun simctl list runtimes выполняется после смены пути.

Если эти пункты не сходятся, проблема ещё не в сети и не в CoreSimulator. Сначала исправьте несоответствие инструментов.

Зависание на «Preparing» не является доказательством одной конкретной причины. В Apple Developer Forums подобные сообщения пользователей рассматриваются как отдельные признаки сбоя, но это не подтверждает наличие универсальной неисправности со стороны Apple в обсуждении Simulator.

Соберите данные до повторной попытки:

date
xcodebuild -version
xcrun simctl list runtimes

Зафиксируйте:

• точное имя запрошенного runtime;
• время начала и окончания попытки;
• домен или URL, к которому обращается процесс;
• текст ошибки и код, если он показан;
• активный прокси, DNS и сетевой интерфейс;
• путь выбранного Xcode.

Дальше разделите причины.

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

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

Проблема конкретного узла. Если другая чистая машина скачивает тот же runtime, а удалённый Mac стабильно возвращается к «Preparing», сравните выбранный Xcode, системное время, свободное место и права пользователя. Слово «стабильно» здесь означает воспроизводимость при одинаковых условиях, а не единичную неудачу.

Командная проверка загрузки должна выполняться из того же Developer Directory:

export DEVELOPER_DIR="/Applications/<Xcode-26.6>.app/Contents/Developer"
xcodebuild -downloadPlatform iOS

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

Эта ситуация выглядит противоречиво только при смешении двух уровней. SDK нужен компилятору. iOS Simulator runtime нужен CoreSimulator для запуска образа операционной системы. Поэтому успешная сборка не отменяет необходимость отдельной установки runtime.

Сравните три источника:

xcodebuild -showsdks
xcrun simctl list runtimes
xcrun simctl list devices

Если -showsdks показывает iOS, а список runtime пуст, вернитесь в Xcode → Settings → Components и проверьте доступные платформы. Apple также описывает добавление Simulator через официальный интерфейс компонентов в руководстве по дополнительным Simulator.

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

Если runtime отображается, создайте тестовое устройство через интерфейс Xcode или simctl, затем запустите его:

xcrun simctl create "<Test-Device>" "<Device-Type>" "<Runtime-Identifier>"
xcrun simctl boot "<Test-Device>"
xcrun simctl list devices

Вместо <Device-Type> и <Runtime-Identifier> подставьте значения, которые реально возвращает simctl list devicetypes и simctl list runtimes. Не используйте имя устройства из чужого скрипта без проверки: доступный тип зависит от установленного набора компонентов.

Ошибки Unavailable, отсутствие загрузки или возврат устройства в выключенное состояние указывают на отдельный сбой CoreSimulator. Сначала перезапустите Xcode и Mac, затем повторите создание устройства. Удаление всех данных CoreSimulator — последний шаг. Перед ним экспортируйте нужные логи и убедитесь, что у вас есть резервный путь восстановления. Такой сброс удаляет локальные устройства, их состояние и связанные тестовые артефакты.

Если сеть на целевом узле ограничена, а другой Mac может корректно скачать нужную платформу, используйте официальный экспорт и импорт компонентов. Это отвечает на вопрос о повторном использовании runtime: да, перенос возможен через поддерживаемый пакет, но не через копирование случайной папки из каталога CoreSimulator.

На исправной машине:

export DEVELOPER_DIR="/Applications/<Xcode-26.6>.app/Contents/Developer"
xcodebuild -downloadPlatform iOS
xcodebuild -exportPlatform iOS -exportPath "<Export-Directory>"

На целевом удалённом Mac:

export DEVELOPER_DIR="/Applications/<Xcode-26.6>.app/Contents/Developer"
xcodebuild -importPlatform "<Export-Directory>"

Названия и доступность параметров нужно проверить по текущей версии xcodebuild и официальной документации. Не переносите пакет между несовместимыми установками, пока не сверены:

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

Команды с <Export-Directory> и <Runtime-Identifier> намеренно используют заполнители. В CI замените их переменными, а значения сохраняйте в журнале задания. Удалённый Mac должен получить именно тот пакет, который был проверен на исходной машине.

Важно: не очищайте каталоги Xcode или CoreSimulator до завершения экспорта и сохранения журналов. Если импорт не сработает, исходное состояние может быть единственным способом восстановить диагностику без полного пересоздания узла.

После импорта выполните:

xcrun simctl list runtimes
xcrun simctl list devices
xcrun simctl boot "<Test-Device>"

Затем запустите минимальное приложение и один тестовый сценарий. Проверка только списка runtime недостаточна: она подтверждает регистрацию, но не загрузку устройства и не запуск тестового процесса. Для проверки связки сборки и Simulator используйте рекомендации Apple по сборке и запуску приложения.

После сетевой попытки и импорта вам нужен не общий вывод «загрузка прошла», а воспроизводимый результат. Проведите проверку через SSH и графическую сессию. Это важно для удалённого Mac: процесс может работать в VNC, но завершаться после отключения SSH, перезагрузки или запуска CI от другой учётной записи.

Финальная проверка:

• [ ] xcode-select -p указывает на ожидаемый Xcode;
• [ ] xcrun simctl list runtimes показывает нужный iOS Simulator runtime;
• [ ] тестовое устройство создаётся или уже присутствует;
• [ ] устройство запускается после перезапуска Simulator;
• [ ] минимальное приложение устанавливается и открывается;
• [ ] один реальный тест проекта выполняется;
• [ ] SSH-сессия может быть закрыта без остановки фоновой задачи;
• [ ] после перезапуска Mac список runtime сохраняется;
• [ ] после повторного запуска Xcode устройство снова доступно.

Для фоновых команд применяйте менеджер сессий или CI-раннер, а не оставляйте критический процесс в обычном интерактивном SSH-сеансе. Это не исправляет runtime, но исключает ложный диагноз, когда загрузка прерывается только из-за закрытия терминала.

Матрица решения после диагностики

Сравнение вариантов восстановления

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

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

Если ваша текущая среда — виртуальная машина или обычный Linux-сервер, она не заменяет реальный macOS-узел для Xcode и Simulator. У такого подхода обычно есть четыре недостатка: отсутствует нативный Apple-инструментарий, сложнее поддерживать совместимость runtime, ручная диагностика занимает больше времени, а после сбоя приходится заново собирать окружение. В этой ситуации аренда Mac у CALMVPS позволяет получить отдельный удалённый Mac с root-доступом и проверить загрузку, импорт и перезапуск на чистой системе без немедленной покупки оборудования. Для начала можно изучить варианты удалённого Mac и отдельно сопоставить их с условиями аренды.

Это не означает, что аренда подходит всем. Для постоянно загруженного узла с долгим сроком эксплуатации покупка собственного Mac может быть выгоднее. Если вам нужны физические USB-устройства, локальный отладчик или оборудование в офисе, удалённая машина тоже не решит задачу. Но для временного CI-узла, проверки Xcode 26.6, восстановления после сбоя и параллельного тестового окружения чистый удалённый Mac часто рациональнее, чем бесконечно очищать нестабильную установку.

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