Xcode 27.1 RC: что делать при ошибке Mac Catalyst? Диагностика 2026

Ошибка появляется при компиляции общего кода iOS и Mac Catalyst или в списке запусков пропала цель Mac Catalyst.

Быстрое решение: сначала сопоставьте симптом с известными проблемами Xcode 27.1 RC. Для вызовов API iOS 27.1 отделите реализацию Catalyst условной компиляцией; если нет цели запуска Catalyst, проверьте минимальную версию развёртывания именно для Catalyst. Успешная сборка iOS сама по себе не подтверждает готовность Mac Catalyst к выпуску. Apple перечисляет оба случая в примечаниях к выпуску Xcode 27.1 RC.

Материал предназначен разработчикам, которые поддерживают общий код iOS и Mac Catalyst и хотят отличить известную проблему инструментария от ошибки проекта.
Он также пригодится небольшой команде, проверяющей несколько Target перед выпуском.
Разработчики удалённого Mac и CI найдут порядок фиксации версии среды и подтверждения результатов.

Последняя проверка: 10 октября 2026 года. Статус и рекомендации сверены с примечаниями Apple для Xcode 27.1 RC и записью Apple Developer о выпуске RC. Это описание относится к указанной версии. Оно не утверждает, что те же проблемы присутствуют в других выпусках Xcode.

Ошибка компиляции Mac Catalyst в Xcode 27.1 RC: границы подтверждённого случая

В примечаниях Apple указаны две связанные, но разные ситуации: при использовании API, предназначенного для iOS 27.1, сборка Mac Catalyst может завершиться ошибкой; для проекта с целевой версией iOS 27.1 может отсутствовать цель запуска Mac Catalyst. Для первой Apple описывает условную компиляцию, для второй — проверку и изменение минимальной версии развёртывания Catalyst. Это разные workaround, и подменять один другим не следует.

Из этого не следует, что любая ошибка с undeclared identifier, has no member или отсутствие Catalyst в списке устройств вызваны именно проблемой RC. Та же диагностика может появиться, если API недоступен для нужной платформы, ветка кода попала не в тот Target, схема не собирает нужную конфигурацию или проект изменился между запусками. Поэтому проверяйте три свидетельства: фактическую версию Xcode, выбранный пункт назначения сборки и первую содержательную ошибку компилятора.

Проверьте номер сборки Xcode и версию macOS в той среде, где произошёл сбой, а не на рабочем компьютере разработчика. Запишите схему, конфигурацию и destination. Сверьте их с официальной записью о версии Xcode: это помогает не приписать инструменту ошибку, воспроизводящуюся только в одном проектном Target.

Для разработчика приложения только для iOS

Если Mac Catalyst не входит в продукт, сначала выясните, включена ли поддержка Catalyst для конкретного Target и схемы. Не исправляйте исходники Catalyst только потому, что сообщение компилятора упоминает платформенный API: при сборке исключительно для iOS такая диагностика может относиться к другому файлу, конфигурации или платформенной ветке.

В Xcode выберите нужную схему и пункт назначения iOS. Затем откройте настройки проекта и цели, проверьте поддерживаемые платформы и флаги сборки. Сверить, где именно задаются параметры, можно в справочнике Apple по настройкам сборки. Для проекта с несколькими Target настройки приложения, расширения и тестов могут различаться; значения одного Target не подтверждают конфигурацию другого.

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

Для владельца общего кода iOS и Catalyst

Почему API iOS 27.1 может ломать сборку Mac Catalyst?

Наличие API в SDK не означает, что его можно без изменений вызывать из всех платформенных вариантов приложения. Если код обращается к элементу, доступному для iOS, но не подходящему Catalyst, общий исходник может не скомпилироваться для Mac Catalyst. Для Xcode 27.1 RC Apple отдельно отмечает такой случай и указывает на разделение кода условной компиляцией.

Сначала найдите в логе первую ошибку, относящуюся к символу, а не последующие сообщения, вызванные неудачной компиляцией зависимого файла. Найдите объявление и все места вызова API. Затем проверьте, включается ли этот файл в сборку Catalyst и есть ли для платформы отдельная реализация. Сведения о поведении платформенных частей и создании версии приложения для Mac Catalyst приведены в документации Apple по коду Mac Catalyst.

Для Swift платформа может быть разделена на уровне компиляции:

#if targetEnvironment(macCatalyst)
func performPlatformAction() {
    // Реализация, совместимая с Mac Catalyst
}
#elseif os(iOS)
func performPlatformAction() {
    // Реализация для iOS
}
#endif

Это иллюстрация структуры, а не готовая замена конкретного API. В Catalyst-ветке должен быть реальный сценарий поведения: альтернативный вызов, безопасное отсутствие функции или вызов общего слоя, подходящего обеим платформам. Если функция не поддерживается на Mac, интерфейс приложения и вызывающий код должны явно учитывать это, а не полагаться на недоступный символ.

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

Ошибки undeclared identifier и has no member сами по себе не устанавливают причину. Сопоставьте символ с платформой в документации, проверьте импорты и активную ветку компиляции, затем соберите каждый целевой вариант. Если исправление заключается в условном исключении вызова из Catalyst, проверьте и эквивалентное поведение: совпадающие сигнатуры функций не гарантируют одинакового пользовательского результата.

Для команды с несколькими Target

В проекте с приложением iOS, Mac Catalyst и вспомогательными Target проверьте каждый вариант отдельно. Один и тот же исходный файл может быть включён в приложение, тесты и расширение с разными настройками. Также возможна ситуация, когда условие написано правильно, но проверяется не та схема или конфигурация.

Порядок проверки:

1. Зафиксируйте коммит, схему, конфигурацию и destination, на котором проявился сбой.
2. В настройках проекта выберите каждый Target и проверьте поддерживаемые платформы, минимальные версии и включённые исходные файлы. Значения сравнивайте с фактическими build settings, а не только с общими настройками проекта.
3. Найдите вызовы спорного API и условия #if. Убедитесь, что Catalyst-ветка не обращается к iOS-only реализации через общий файл или обёртку.
4. Проверьте, не переопределяет ли Target настройки проекта. Для новой цели ориентируйтесь на документацию Apple по настройке Target.
5. Соберите iOS и Catalyst с одного коммита. Если отличается только один вариант, приложите его build settings и полный лог первой ошибки.
6. После изменения повторите обе сборки. Изменение, исправившее Catalyst, не должно незаметно сломать путь iOS или иной Target.

Для фиксации настроек пригодится команда:

xcodebuild -showBuildSettings \
  -scheme "ИмяСхемы" \
  -destination 'generic/platform=macOS,variant=Mac Catalyst'

Подставьте схему своего проекта. Список поддерживаемых назначений можно проверить отдельно:

xcodebuild -showdestinations -scheme "ИмяСхемы"

В выводе ищите выбранную схему и значения, относящиеся к поддерживаемым платформам и минимальной версии развёртывания. Не трактуйте отсутствие одной строки в отрывке лога как доказательство неисправности: сохраните полный вывод и сравните его со сборкой iOS. Конкретные доступные параметры зависят от проекта и версии средств сборки; их назначение следует сверять со справочником настроек Apple.

Для владельца Catalyst: пропавшая цель запуска

Что проверить, если Xcode 27.1 RC не показывает цель Mac Catalyst?

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

Изменяйте именно значение, связанное с Catalyst, и только после проверки применимости ситуации. Не переносите произвольное значение на другие платформы и не считайте это универсальным исправлением ошибки API. Если проект не использует Mac Catalyst или не соответствует известному условию, сначала проверьте включение платформы для нужного Target, схему и настройки проекта.

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

Для ответственного за удалённый Mac или CI

Ошибка на CI может быть следствием отличающегося инструментария, настроек или исходников. В журнале задания сохраните полный вывод xcodebuild -version, сведения о macOS, коммит, схему, конфигурацию, destination и первую содержательную ошибку. Если локальная машина собирает проект, а CI — нет, сравните эти сведения до изменения кода. Не делайте вывод об известной проблеме только по тому, что ошибка возникла на удалённом Mac.

Повторите на том же коммите отдельные сборки для iOS и Catalyst. Для проверки можно использовать явные назначения, например:

xcodebuild \
  -scheme "ИмяСхемы" \
  -destination 'generic/platform=iOS' \
  build

xcodebuild \
  -scheme "ИмяСхемы" \
  -destination 'generic/platform=macOS,variant=Mac Catalyst' \
  build

Затем выполните Archive для соответствующей схемы и Catalyst destination:

xcodebuild \
  -scheme "ИмяСхемы" \
  -destination 'generic/platform=macOS,variant=Mac Catalyst' \
  -archivePath "/путь/к/каталогу/Приложение.xcarchive" \
  archive

Команды — шаблоны: замените имя схемы и путь своими значениями, а параметры подписи задайте согласно проекту. Успешный build не равен успешному Archive. В CI сохраните exit code, журнал целиком и результат проверки созданного архива. Затем отдельно проверьте конфигурацию выпуска и дальнейший шаг распространения: руководство Apple по Archive, тестированию и выпуску описывает соответствующий процесс. Проверка одного этапа не заменяет остальные.

Условная компиляция, изменение настройки или ожидание обновления

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

Для производственного выпуска результат каждой платформы фиксируйте отдельно. Если Catalyst входит в текущий релиз, не публикуйте его на основании успешной сборки iOS. Если Catalyst не входит в область поставки, задокументируйте это решение и не изменяйте настройки iOS ради неиспользуемой цели. Когда проблема остаётся после применения подходящего workaround, сохраните проектный лог и повторно проверьте примечания к последующему выпуску Xcode; RC-описание не гарантирует, что проблема сохраняется в следующем выпуске.

Перед объединением исправления отметьте пункты, которые действительно прошли проверку:

• [ ] Зафиксированы версия Xcode, версия macOS, коммит, схема и destination.
• [ ] Первая содержательная ошибка сопоставлена с платформой и исходным символом.
• [ ] Для API iOS 27.1 проверены доступность и отдельная ветка Mac Catalyst.
• [ ] Для отсутствующей цели проверены Catalyst-настройки и минимальная версия развёртывания.
• [ ] Один и тот же коммит собран отдельно для iOS и Mac Catalyst.
• [ ] Для платформы, входящей в релиз, завершены Archive и проверка полученного артефакта.
• [ ] В журнале CI сохранены команды, полный вывод и результаты каждого Target.

Если нужен постоянный контур, сравните его содержание с текущим способом сборки, прежде чем переносить проект. Общий CI может не давать удобного доступа к интерактивной macOS-среде, а локальный Mac может оказаться недоступен команде или перегружен посторонними задачами; это зависит от конкретной конфигурации, а не от одного названия решения. Для разового воспроизведения или временной проверки отдельной схемы удалённый Mac позволяет изолировать работу от локальной машины, но для непрерывной тяжёлой нагрузки собственный выделенный Mac может быть рациональнее. Условия аренды и доступные варианты можно сравнить на странице тарифов SFTPMAC.

Если для проверки нужен отдельный macOS-контур, а покупать и обслуживать ещё один Mac ради временной диагностики нецелесообразно, рассмотрите заказ удалённого Mac у SFTPMAC. На нём следует повторить сборку именно для нужных Target, затем проверить Archive и артефакт. Такой результат полезен только при зафиксированных версиях инструментов и совпадающем коммите: аренда даёт отдельную среду, но не заменяет проверку проекта и не доказывает готовность платформы без этих шагов.