Требования к загрузке SDK Xcode 27: контрольный список для CI на 2026 год

С апреля 2027 года приложения, которые загружаются в App Store Connect, должны соответствовать объявленным Apple минимальным требованиям к SDK для своей платформы. В требованиях Apple перечислены платформы и срок вступления правила в силу. Поэтому не переключайте все производственные CI без проверки: на этой неделе выделите изолированное окружение, установите фактические версии Xcode и SDK, затем переводите проекты поэтапно — после проверки сборки, тестов, архива, подписи и загрузки.

Кому пригодится этот план: инженерам Apple-платформенного CI, которым нужно выяснить, какой toolchain действительно запускает сборки.
Руководителям релизов, проверяющим путь от архива до App Store Connect.
Руководителям платформенной разработки, планирующим переход нескольких проектов и команд.

Последняя проверка: 30 октября 2026 года. Срок и охват требования сверены с объявлением Apple; состояние Xcode и его выпусков нужно дополнительно сверять с официальной страницей Apple Developer Releases. Перед каждой волной перехода проверяйте актуальные материалы: Apple может обновить требования и сведения о доступных инструментах.

Требования к загрузке SDK Xcode 27: что именно нужно проверить

По опубликованному Apple требованию, с апреля 2027 года приложения, загружаемые в App Store Connect, должны использовать iOS/iPadOS 27 SDK, tvOS 27 SDK, visionOS 27 SDK и watchOS 27 SDK либо более новые версии. Область действия — приложения, отправляемые в App Store Connect. Это не означает, что всем задачам в macOS CI нужно немедленно назначить новый образ runner или что для каждого проекта следует менять deployment target.

При планировании разделите три разных вопроса:

• Какой SDK использует приложение при сборке? Это нужно проверить для целевых платформ и конфигураций, участвующих в выпуске.
• Какая версия Xcode содержит нужный SDK? Ответ должен опираться на официальные сведения о конкретном выпуске, а не на предположение по номеру Xcode.
• Входит ли задача в маршрут загрузки приложения? Внутренние проверки и сборки, которые не отправляются в App Store Connect, не следует автоматически включать в массовую миграцию.

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

Минимальное требование к SDK нельзя приравнивать к минимальной версии операционной системы, которую поддерживает приложение. Это разные настройки: отдельно проверьте выбранный SDK и deployment target. Значение настроек и их назначение сверяйте со справочником Apple по параметрам сборки Xcode.

Для каждой платформы отмечайте, есть ли соответствующий target, каким способом его собирают и передают ли итоговый артефакт в App Store Connect. Один проект может включать несколько Apple-платформ и иметь разные маршруты для приложения, framework и внутренних проверок. В такой ситуации классифицируйте не только репозиторий целиком, но и конкретные задачи CI: это позволит не расширить область перехода без необходимости.

Проверка приоритетов: от фактической среды к результату публикации

Ниже — сравнительная оценка того, какие части процесса требуют внимания при подготовке. Оценки качественные: они помогают расставить приоритеты, а не предсказывают сроки или вероятность успеха.

• Фактическая версия Xcode — приоритет высокий. Если настройки workflow и реально выбранный developer directory расходятся, команда может проверить не тот toolchain.
• Совместимость проекта и зависимостей — приоритет высокий. На результат влияют настройки проекта, сторонние библиотеки, генераторы, shell-скрипты и обработка ресурсов.
• Платформенные тесты — приоритет зависит от охвата проекта. Он повышается, если приложение поддерживает несколько платформ или использует сценарии, не покрытые обычной компиляцией.
• Архив, подпись и загрузка — приоритет высокий для выпускаемых приложений. Успех компиляции не подтверждает, что CI подготовил и отправил нужный релизный артефакт.
• Задачи вне App Store Connect — приоритет перехода низкий, пока нет технической причины менять среду. Для них достаточно явно описать текущие ограничения и критерии повторного рассмотрения.

Это сравнение показывает, куда направить проверку, но не заменяет приёмку конкретного проекта. Например, успешно собранный framework не доказывает, что приложение, которое его использует, удастся заархивировать, подписать и загрузить. Аналогично, общий статус успешного workflow не раскрывает, какой именно этап был выполнен и какие доказательства сохранились.

Первый этап: владелец toolchain фиксирует состояние узла

До изменения конфигурации снимите состояние работающего CI-узла. В диагностический шаг workflow или скрипт проверки добавьте команды:

xcode-select -p
xcodebuild -version
xcodebuild -showsdks

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

Сопоставьте четыре источника: образ или метку runner в workflow, путь developer directory, журнал фактической команды сборки и сведения о полученном артефакте. Если данные не совпадают, сначала устраните расхождение или внесите его в план проверки. Иначе можно потратить время на тестирование одной версии Xcode, хотя рабочая сборка продолжает запускать другую.

Создайте отдельную ветку или workflow для нового инструментария. Не меняйте в одном эксперименте Xcode, зависимости, настройки подписи и логику публикации: если сборка упадёт, вам будет сложно определить, какое изменение вызвало отказ. Сохраняйте идентификатор коммита, команду запуска, журнал и результат. Запись должна позволять повторить прогон и понять, какую именно конфигурацию проверяли.

Для сравнения с текущим состоянием соберите минимальную карточку toolchain: где установлен Xcode, как он выбирается, какие SDK доступны и какой workflow использует его для каждого платформенного target. Не заменяйте эту карточку одной лишь меткой runner. Метка может быть полезна для маршрутизации задачи, но сама по себе не является доказательством фактически выбранного Xcode или набора SDK.

Второй этап: сопровождающий проекта проверяет совместимость

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

Запустите чистую сборку в изолированном workflow. Если она отличается от действующего процесса, запишите команду, target, фрагмент журнала и условия воспроизведения. Разделите причины отказа: компиляция исходников, разрешение зависимостей, выполнение скрипта, генерация файлов или настройка проекта. Точная классификация поможет определить владельца исправления и позволит избежать широких изменений, не относящихся к проблеме.

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

Каждому проекту присвойте один из трёх статусов:

• Готов к следующей проверке: сборка воспроизводится, существенных ошибок нового инструментария не выявлено.
• Нужно исправление: найден отказ с воспроизводимыми условиями и назначенным владельцем.
• Не входит в текущий маршрут требования: задача не отправляет приложение в App Store Connect; её ограничения описаны отдельно.

Статус «готов к следующей проверке» не означает, что проект уже допущен к выпуску. Он только разрешает перейти к платформенным тестам и проверке релизных этапов. Такое различие нужно сохранять и в отчётах: иначе промежуточный успех может быть ошибочно воспринят как завершённая миграция.

Третий этап: тестировщик принимает платформенные проверки

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

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

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

Разделяйте наблюдения и выводы. Например, запись «набор тестов завершился» подтверждает выполнение набора в указанной конфигурации, но не доказывает, что релизный архив подписан правильно и принят App Store Connect. Чтобы обосновать общий вывод о готовности, соедините результаты тестов с проверками архива, подписи и загрузки.

Четвёртый этап: релизный инженер проверяет архив, подпись и загрузку

Проведите пробный релиз с конфигурацией, соответствующей реальному маршруту команды. Проверьте создание архива, ожидаемый состав артефакта, подпись, необходимые этапы обработки и передачу сборки в App Store Connect. Сведения о назначении сертификатов сверяйте с обзором сертификатов Apple, а требования к загрузке — с инструкцией Apple по загрузке сборок в App Store Connect.

Фиксируйте результат каждого этапа отдельно:

• Сборка прошла. Процесс завершился, но создание релизного архива ещё не подтверждено.
• Архив создан. Получен ожидаемый результат, однако подпись и загрузка остаются отдельными проверками.
• Подпись и обработка проверены. Сохранены сведения, подтверждающие настройки конкретного релизного маршрута.
• Загрузка принята App Store Connect. Зафиксирован соответствующий результат в системе; это не равнозначно одобрению приложения к публикации.

Сопоставьте шаги с документацией Apple по распространению приложений и выпускам. Проверяйте именно тот путь, который использует команда, а не отвлечённый статус «CI успешно завершилась». Не объявляйте приёмку законченной только по коду возврата команды архивации: у архива, подписи и передачи в App Store Connect разные критерии успешного завершения.

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

Используйте этот контрольный список для каждого проекта отдельно. Отметьте пункты по результатам пробного прогона, а не по настройкам, которые лишь предполагают нужное состояние.

• [ ] Проект загружает приложение в App Store Connect. Если нет, не включайте его автоматически в переход по требованию к загрузке; зафиксируйте отдельные ограничения и вернитесь к решению при изменении маршрута.
• [ ] Фактически использованные Xcode и SDK установлены по журналам CI. Если нет, оставьте проект в изолированном контуре и сначала исправьте диагностику или расхождение с конфигурацией runner.
• [ ] Соответствие Xcode и SDK подтверждено официальными материалами Apple. Если нет, не выводите версию SDK из номера Xcode; проверьте официальные сведения о выпусках и системных требованиях.
• [ ] Сборка и необходимые платформенные тесты приняты. Если нет, назначьте владельца конкретного отказа и не переводите производственный релизный маршрут.
• [ ] Архив и подпись проверены в конфигурации, используемой для выпуска. Если нет, продолжайте приёмку в тестовом маршруте и сохраните данные о проблеме.
• [ ] Загрузка в App Store Connect завершилась ожидаемым результатом. Если нет, не считайте успешную компиляцию или создание архива достаточным основанием для переключения.
• [ ] Для общего runner определены затронутые workflow и способ возврата к прежней среде. Если нет, не меняйте общий узел до согласования с владельцами проектов.

Решение по итогам списка:

• Все относящиеся к проекту пункты отмечены — допускайте проект к поэтапному переключению и сохраните подтверждающие материалы.
• Не подтверждены Xcode, SDK или охват требования — продолжайте изолированный прогон; не переносите предположение в производственную конфигурацию.
• Не пройдены тесты, архив, подпись или загрузка — остановите переключение этого релизного маршрута, назначьте ответственного и повторите проверку после исправления.
• Проект не отправляет приложение в App Store Connect — оставьте его в отдельной категории и меняйте среду только при наличии самостоятельной технической причины.

Если несколько команд пользуются общим runner, сначала выясните, какие workflow затрагивает смена среды, и согласуйте порядок с владельцами проектов. Сроки планируйте по реальному календарю релизов и результатам команды: официальное окно Apple — апрель 2027 года, но оно не сообщает, сколько времени потребуется конкретному проекту на адаптацию. Не подставляйте в план универсальную оценку длительности или ожидаемой успешности: проекты отличаются платформами, зависимостями, настройками релиза и объёмом проверок.

Для каждого решения зафиксируйте владельца, проверяемые платформы, текущий статус, оставшиеся отказы, критерии допуска и способ возврата к прежней среде. Если команда откладывает переход, укажите условие повторного рассмотрения — например, подтверждение соответствия SDK официальными материалами или готовность исправления зависимости. Так отсрочка становится управляемым решением, а не бессрочной паузой.

Частые вопросы о подготовке Apple-платформенного CI

Как понять, какие проекты затрагивает требование?

Сопоставьте перечень приложений с фактическим маршрутом доставки и укажите платформу каждого отправляемого приложения. Включите в приёмку те проекты, которые загружаются в App Store Connect. Не распространяйте требование автоматически на внутренние сборки, framework и проверочные задачи, если они не участвуют в этом маршруте. При этом отдельно сохраните их собственные ограничения по инструментарию.

Нужно ли менять deployment target вместе с SDK?

Автоматически повышать deployment target только из-за требования к SDK не нужно. SDK — инструмент сборки, а deployment target определяет минимальную версию операционной системы, на которую рассчитано приложение. Зафиксируйте оба значения отдельно и обоснуйте каждое изменение собственными требованиями проекта. Это поможет не отказаться без продуктового решения от поддержки уже заявленных версий ОС.

Какие доказательства нужны для приёмки пробного запуска?

Соберите сведения о фактически выбранных Xcode и SDK, команду сборки, журнал, результаты платформенных тестов, информацию об архиве и подписи, а также статус загрузки в App Store Connect. Свяжите материалы с проектом и проверяемым коммитом, назначьте ответственного за каждый незавершённый пункт. Если этап пропущен, обозначьте это прямо: отсутствие ошибки компиляции не подтверждает завершённость релизной приёмки.

Как распределить переход между проектами разных платформ?

Составьте отдельный перечень для iOS/iPadOS, tvOS, visionOS и watchOS, затем укажите, какие проекты действительно публикуются через App Store Connect. Запускайте новый toolchain изолированно и переводите проекты по мере готовности их собственного релизного маршрута. Общий runner меняйте после того, как проверены его пользователи и определён порядок отката; не переносите все задачи одним решением без проверки их назначения.

Выбирайте среду по результатам проверки, а не по метке runner

Действующая CI может быть удобна, но у неё есть ограничения: образ runner не всегда доказывает, какой Xcode был выбран; общий узел затрудняет независимое тестирование; недостаточные журналы мешают установить причину отказа. Локальный Mac даёт команде непосредственный контроль, однако не всегда подходит как отдельная среда для изолированного и доступного всей команде прогона. Сопоставьте контроль над macOS-инструментами, доступ и сохранение результатов проверки с реальным назначением каждой задачи.

Если для пробного маршрута нужен отдельный Mac, но вы не готовы покупать и обслуживать собственную машину до завершения проверки, удалённая аренда VPSMAC может быть вариантом для изолированного прогона. Сначала подтвердите на выбранной среде фактический Xcode и SDK, а затем соберите те же доказательства тестирования, архива, подписи и загрузки, что потребуются для решения о переходе. Доступные варианты можно изучить в каталоге VPSMAC, а условия сервиса — на странице VPSMAC.

Для непрерывной тяжёлой нагрузки или процессов, которым необходимы конкретные физические интерфейсы и устройства, сравните удалённую среду с собственным Mac: аренда не отменяет оценки этих ограничений. Если же задача — временно подтвердить совместимость Xcode и SDK на реальном macOS CI, начните с отдельного прогона и переходите дальше только по сохранённым результатам.