15 октября 2026 года GitHub объявила о доступности образа Runner с Xcode 27: он работает на macOS 27 и предназначен только для Apple Silicon по официальному объявлению. Поэтому не переустанавливайте Xcode наугад: сначала зафиксируйте фактический образ задачи и активный Xcode, затем проверьте Simulator Runtime, список устройств и условия destination.

Материал пригодится инженерам CI, которые только перешли на Runner с Xcode 27 и проверяют iOS Simulator.
Он также адресован разработчикам, у которых xcodebuild не находит destination или сообщает об отсутствующем Runtime.
DevOps-инженеры смогут использовать порядок проверок, чтобы решить, оставлять ли задачу на hosted Runner.

Последняя проверка сведений об образе — 17 октября 2026 года; сверяйте актуальное состояние с объявлением GitHub и README образа: их содержимое может обновляться.

Зафиксируйте, на каком этапе ломается задача

Сообщение Unable to find a destination matching the provided destination specifier означает, что xcodebuild не смог сопоставить заданные условия с доступными назначениями для конкретного запуска. Само по себе оно не доказывает, что Simulator вообще не установлен. Сбой мог произойти до сборки, при выборе назначения теста или уже после выбора устройства — при запуске Simulator либо тестового процесса.

Сначала определите этап по журналу, а не по последней строке ошибки:

  • Если сборка завершилась ошибкой компиляции, проверяйте исходники, SDK и параметры сборки. Это не тот же случай, что отказ сопоставить destination.
  • Если сборка прошла, но тестовый процесс не стартовал, найдите команду теста и ошибку, предшествующую завершению задачи.
  • Если xcodebuild перечисляет доступные destinations, но среди них нет запрошенного, сравните условия команды с этим списком.
  • Если устройство выбрано, но не запускается, фиксируйте отдельный сбой запуска или тестирования. Не называйте его ошибкой поиска устройства без подтверждения.

Откройте конкретный запуск workflow и сохраните полный журнал шага, который вызывает сборку или тест. В GitHub Actions журналы доступны в интерфейсе запуска workflow; ориентируйтесь на инструкцию GitHub по просмотру журналов. Запишите фактическую метку Runner, имя образа, команду, схему и полный текст ошибки. Метка в YAML — не доказательство того, какой образ и набор компонентов использовались в конкретной задаче.

Если проблема воспроизводится только в одном запуске, сохраните его журнал до повторного запуска. Новый Runner может получить обновлённое содержимое образа, поэтому поздний вывод не всегда описывает первоначальную среду.

Проверьте схему и параметры destination

Когда xcodebuild не находит подходящее назначение, первым делом выясните, что именно просит команда и что доступно выбранной схеме. Имя устройства, версия системы и платформа — самостоятельные условия. Ошибка в любом из них может привести к пустому совпадению, даже если в образе есть Simulator.

Получите список назначений с тем же проектом и схемой, которые указаны в workflow:

xcodebuild -showdestinations \
  -scheme "ИмяСхемы" \
  -project "Проект.xcodeproj"

Если workflow собирает workspace, используйте его вместо параметра -project:

xcodebuild -showdestinations \
  -scheme "ИмяСхемы" \
  -workspace "Проект.xcworkspace"

Сверьте результат с аргументами тестового шага:

  • Платформа. В тестовой команде должна запрашиваться платформа, соответствующая тестовому target. Устройство iOS Simulator не подходит для схемы или target, настроенного только для другой платформы.
  • Схема и target. Убедитесь, что выбранная схема действительно включает нужный тестовый target. Проверьте настройки схемы в репозитории, а не только имя, указанное в YAML.
  • Версия ОС. Сравните OS в destination с установленными Runtime. Если команда закреплена за версией, которой нет в образе, автоматический выбор другого Runtime не решит проблему.
  • Имя или идентификатор устройства. Сверьте точное имя с выводом -showdestinations. Не переносите имя из локальной машины, если список на Runner отличается.

Для повторяемой диагностики добавьте временный шаг с xcodebuild -showdestinations перед тестированием и публикуйте его вывод вместе с логами. Так вы увидите, не изменился ли список назначений после обновления образа. Не делайте вывод о доступности устройства по YAML: запрос destination и реально перечисленные значения нужно сравнить в одном и том же запуске.

Сопоставьте Runtime с фактическим образом

Если сообщение говорит, что платформа или Runtime недоступны, проверьте компоненты выбранного Xcode. Для этого недостаточно посмотреть только на версию Xcode. Важно выяснить, какие Simulator Runtime и типы устройств доступны именно текущему xcodebuild.

Выполните в задаче:

xcrun simctl list runtimes
xcrun simctl list devices available

Сохраните оба вывода. Первый показывает доступные Runtime; второй помогает проверить, какие устройства перечислены для установленной среды. Затем сравните их с версией ОС, именем устройства и платформой в destination. Сведения о составе образа сверяйте с README Runner для Xcode 27, а не с логом от старого запуска.

Здесь важно различить несколько ситуаций:

  • Запрошенная версия ОС отсутствует среди Runtime — сначала проверьте, предусмотрена ли она в актуальном образе.
  • Runtime присутствует, но ожидаемого типа устройства нет в simctl list devices available — проверьте доступные устройства и условия destination.
  • Устройство и Runtime есть, но -showdestinations не предлагает их для схемы — вернитесь к платформе и конфигурации target.
  • Назначение найдено, но запуск Simulator не проходит — изучайте ошибку запуска отдельно от выбора destination.

В опубликованном объявлении GitHub указаны образ macOS 27 с Xcode 27 и два варианта меток: xcode-27 и xcode-27-xlarge; для этого образа заявлены только Runner на Apple Silicon. Актуальность этих сведений проверяйте по объявлению. Ни объявление, ни текущий README не являются гарантией, что один и тот же перечень Runtime останется неизменным для каждого последующего запуска.

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

Убедитесь, что команда использует нужный Xcode

На Runner могут быть доступны несколько версий Xcode или разные настройки выбора developer directory. Поэтому наличие Xcode 27 в образе ещё не подтверждает, что команда xcodebuild использует именно его.

Добавьте перед сборкой диагностические команды:

xcode-select -p
xcodebuild -version
which xcodebuild

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

Apple описывает выбор активного каталога инструментов и проверку командных средств в документации по настройке Command Line Tools. Используйте её для проверки xcode-select, а не предполагайте, что версия, указанная в комментарии к workflow, соответствует активной версии в процессе.

Особенно внимательно проверьте случай, когда в выводе xcode-select -p путь ожидаемый, но команда всё равно выбирает не то назначение. Тогда сравните xcodebuild -version, список Runtime и -showdestinations: возможно, выбранный Xcode активен, но нужный Simulator Runtime отсутствует или схема не поддерживает запрошенную платформу. Эти причины требуют разных исправлений.

Сверьте устройства и состояние запуска

Список доступных устройств — контрольная точка, а не повод угадывать имя Simulator. Снимите xcrun simctl list devices available непосредственно в проблемном запуске и сопоставьте с workflow точное имя, идентификатор и версию ОС. Если команда использует UDID, убедитесь, что он относится к Runner этого запуска, а не скопирован из локальной среды.

Затем проверьте, где именно прекращается выполнение. Если xcodebuild -showdestinations нашёл назначение, а тестовая команда выбрала его, ошибка больше не относится к отсутствующему destination. Сохраните полный вывод xcodebuild, журналы тестового шага и результат тестирования. Они помогут отделить невозможность подобрать устройство от ошибки старта Simulator, сбоя приложения или падения теста.

Сценарий. После смены метки на xcode-27 тестовая команда продолжает запрашивать фиксированную версию iOS. В журнале сборка проходит, но xcodebuild не находит соответствующее назначение. В такой ситуации полезнее сопоставить запрошенную версию с simctl list runtimes и -showdestinations, чем менять сам тестовый target. Если список показывает другое доступное назначение, причина — в условии запроса; если Runtime отсутствует, проверяйте состав текущего образа. Это пример диагностической развилки, а не утверждение об официально подтверждённой неисправности Runner.

Для автоматизированных тестов сохраняйте артефакты, которые позволят воспроизвести разницу между успешным и неуспешным запуском: вывод команд проверки среды, лог xcodebuild и результат тестов. В документации Apple по автоматизированному тестированию описаны основы автоматизации тестов Xcode. Применяйте их вместе с диагностикой конкретной среды, не подменяя журнал выполнения предположением о состоянии Simulator.

Используйте проверочный список перед изменением workflow

Пройдите пункты на том же Runner, где возникла проблема. Если любой ключевой пункт не подтверждён, устраните неопределённость до переустановки инструментов или изменения проекта.

  • [ ] Записана метка Runner и фактическое имя образа из журнала проблемного workflow.
  • [ ] Сохранены полная команда теста и полный текст ошибки, включая шаг, на котором она появилась.
  • [ ] xcode-select -p, xcodebuild -version и which xcodebuild указывают на ожидаемый инструмент.
  • [ ] xcrun simctl list runtimes содержит Runtime, соответствующий запрошенной версии ОС.
  • [ ] xcrun simctl list devices available перечисляет нужный тип устройства.
  • [ ] xcodebuild -showdestinations для той же схемы показывает назначение, которое запрашивает тест.
  • [ ] Платформа схемы и тестового target совпадает с платформой destination.
  • [ ] После исправления повторён тот же commit с теми же схемой и параметрами, а диагностика сохранена.

Преимущество такого порядка — вы меняете один подтверждённый источник расхождения за раз. Недостаток — при плавающем составе hosted-образа диагностику нужно повторять в каждом новом запуске, а подготовка Runtime может потребовать отдельного шага.

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

Решите, когда изолировать задачу на Mac

Оставляйте тест на GitHub-hosted Runner, если нужный Xcode и Runtime доступны, destination совпадает со схемой, а повторный запуск на том же commit даёт воспроизводимый результат. Уточните в workflow диагностику версии инструментов, чтобы следующее обновление образа не скрывало причину различий. Информацию о границах и составе hosted Runner сверяйте с документацией GitHub по Runner.

Переход к отдельной среде Mac стоит оценивать, если нужные Runtime или состояние хоста недоступны на hosted Runner, установка компонентов не подходит вашей модели выполнения либо требуется контролировать конфигурацию между тестовыми запусками. Решение принимайте после воспроизведения, а не по одному сообщению destination not found.

При проверке переноса используйте тот же commit, схему и параметры тестирования. Зафиксируйте версию Xcode, вывод Runtime и устройств, факт старта Simulator и результаты тестов. Если вы рассматриваете удалённую среду для CI, начните с обзора вариантов доступа к Mac и оцените отдельный узел только для тех задач, которым действительно нужна контролируемая macOS-среда. Для временной проверки можно изучить вариант заказа Mac mini. Это не отменяет hosted Runner для задач, которые там стабильно выполняются, и не заменяет реальные устройства при проверке устройства-специфичного поведения.

Частые вопросы

Почему Runner с меткой Xcode 27 не видит iOS Simulator?

Метка задаёт тип Runner, но сама по себе не подтверждает, какой образ и набор компонентов использовала конкретная задача. Сверьте фактический образ в журнале запуска с README образа, затем проверьте активный Xcode, установленный Simulator Runtime и destinations, которые видит выбранная схема. Эти проверки отделяют несовпадение конфигурации от отсутствующего компонента.

Как посмотреть, какой Simulator Runtime доступен на xcode-27?

В шаге диагностики выполните xcodebuild -version, xcode-select -p и xcrun simctl list runtimes, а затем сохраните вывод в журнале задачи. Сопоставьте список с версией ОС в destination. Если нужного Runtime нет, проверьте актуальный README образа: опубликованный список относится к конкретному состоянию образа и не гарантирует неизменный состав будущих Runner.

С чего начать, если xcodebuild сообщает, что destination не найден?

Сначала запустите xcodebuild -showdestinations для той же схемы и workspace или проекта, которые использует тестовая команда. Сверьте платформу, имя устройства и версию ОС с запрошенным destination, а также проверьте, что схема содержит подходящий тестовый target. Не начинайте с переустановки Xcode: сначала установите, какое условие не совпало.

Когда тесты Simulator стоит перенести на удалённый Mac?

Рассматривайте отдельный Mac, если нужные Xcode, Runtime или состояние хоста невозможно надёжно получить на hosted Runner, а повторяемость важна для выпуска. Сначала подтвердите сбой на одном commit и сохраните журналы. Отдельный Mac не заменяет проверку на физическом устройстве: он даёт контролируемую macOS-среду, но Simulator и реальный iPhone проверяют разные условия.

Если причина сводится к метке, неверно выбранному Xcode или несовпадающему destination, сначала исправьте workflow: это быстрее и не требует переносить задачу. Если же необходимые Runtime или контролируемое состояние хоста нельзя обеспечить на hosted Runner, повторите тест на выделенной среде Mac и сравните журналы по одному commit. Для временной диагностики или изолированного CI-задания аренда Mac у MACCOME может быть удобнее, чем покупка отдельного компьютера; для постоянной тяжёлой нагрузки или тестов, которым нужен физический интерфейс, заранее оцените собственное оборудование и реальное устройство.