Требование App Store к SDK 2027: когда в 2026 году переносить сборочную машину?

Что именно потребует App Store с апреля 2027 года

Apple объявила, что начиная с апреля 2027 года загружаемые в App Store Connect приложения для iOS и iPadOS должны быть собраны с iOS 27 и iPadOS 27 SDK или более новыми версиями. Формулировка относится к SDK, с которым создана сборка; это не автоматическое изменение минимальной версии операционной системы, на которой приложение вправе запускаться. Дата и область действия указаны в объявлении Apple.

Для плана миграции важно вести раздельно три параметра:

• SDK сборки — набор заголовков, библиотек и инструментов, использованных Xcode при компиляции и архивировании.
• Целевая версия развёртывания — нижняя граница iOS или iPadOS, заявленная приложением. Её изменение может исключить пользователей старых устройств, поэтому оно требует отдельного продуктового решения.
• Версия Xcode и поддерживаемая macOS — сочетание, которое определяет, можно ли запустить нужный компилятор и выполнить выпуск на конкретном Mac. Совместимость нужно проверять по требованиям Xcode к системе и примечаниям к конкретному выпуску, а не выводить из названия чипа.

Таким образом, ответ на вопрос о минимальной версии iOS — нет, одно лишь требование SDK не заставляет выставлять iOS 27 как deployment target. Однако команда должна убедиться, что настройки проекта сохраняют нужную поддержку старых устройств, а используемый SDK соответствует требованию.

До переноса: зафиксируйте текущий путь выпуска

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

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

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

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

sw_vers
uname -m
xcodebuild -version
xcode-select -p
xcodebuild -showsdks

Они помогают зафиксировать версию macOS, архитектуру хоста, выбранный путь к Xcode и доступные SDK. Это только инвентаризация: наличие SDK в выводе не доказывает, что проект успешно архивируется, подписывается и проходит загрузку. Сохраните вывод вместе с названием среды и отметьте, где он был получен.

Затем выпишите путь выпуска по шагам. Например: репозиторий → исполнитель CI или локальный Mac → Archive → подписание → загрузка в App Store Connect → обработка сборки → выбор сборки для отправки. Для каждого перехода укажите используемую учётную запись, хранилище сертификатов и профиль подготовки, переменные CI, секреты и способ получить итоговый архив.

Это выявляет незаметные риски, которые не видны по версии Xcode:

• Несовпадающий инструментальный набор. Разработчик проверяет проект на одном Xcode, а сборочная машина использует другой. Ошибка может проявиться в настройках сборки, компиляции зависимости или создании архива.
• Скрытая зависимость от секретов. Новый Mac может собирать код, но не подписывать приложение, если сертификат, профиль подготовки, ключи или права доступа не перенесены и не проверены.
• Разные маршруты выпуска. Успешный локальный архив не подтверждает корректную работу скрипта CI или возможность загрузки из резервной среды.
• Цена преждевременного переключения. При замене единственной производственной машины становится сложнее быстро откатиться на проверенное окружение, если выпуск нужно подготовить до окончания миграции.

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

Первый этап проверки: действительно ли старый проект готов к новому Xcode

Не переносите все приложения одновременно. Для проверки выберите проект, который представляет наиболее высокий риск: например, тот, у которого больше зависимостей, собственных build phases, расширений, конфигураций подписи или нестандартных скриптов. Если приложения существенно различаются, одного «простого» проекта недостаточно: он может подтвердить только то, что простая конфигурация собирается.

Заведите отдельную ветку или копию проекта и используйте изолированное целевое окружение. До изменений сохраните исходное состояние настроек и результаты прежней сборки. Затем проверьте:

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

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

xcodebuild \
  -workspace "Путь/к/Проекту.xcworkspace" \
  -scheme "НазваниеСхемы" \
  -showBuildSettings

Замените значения в кавычках на реальные путь и схему своего проекта. Из результата выпишите параметры SDK и deployment target, а не полагайтесь на один экран настроек Xcode. Если проект использует .xcodeproj, укажите его вместо -workspace и передайте соответствующий параметр проекта.

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

Когда старому iOS-приложению переходить на новый Xcode

Перенос имеет смысл начинать в 2026 году, когда уже можно выделить среду для проверки и пройти выпускной путь без риска для текущей публикации. Не требуется менять рабочую машину в день объявления. Но откладывать проверку до последнего момента опасно: совместимость проекта, подпись и загрузка — разные задачи, и каждая может потребовать отдельной доработки.

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

Второй этап: выберите безопасный режим переключения

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

• Оставить прежнюю среду основной, новый инструмент проверять изолированно. Этот вариант подходит, если релиз предстоит раньше, чем команда завершит регрессионную проверку. Старая машина остаётся путём отката, но тестовая среда должна быть отделена от её сертификатов, файлов и рабочих настроек.
• Запустить старый и новый процессы параллельно. Это разумно, когда текущие исправления ещё могут потребовать старого Xcode, а проекты уже проходят проверку новой связкой. Заранее определите, какая среда создаёт официальный архив для конкретного релиза; не допускайте, чтобы один и тот же процесс выбирал Xcode по случайному глобальному переключателю.
• Заменить или дополнить хост. Рассматривайте это, если официальный список совместимости исключает текущую систему или нельзя безопасно поддерживать обе версии инструментов. Сначала сравните обновление имеющегося Mac, отдельную машину и временную удалённую среду, включая доступ к секретам, резервирование и восстановление.

Для параллельной проверки полезно явно выбрать Xcode в конкретной команде, а не менять системный выбор для всех пользователей и задач:

DEVELOPER_DIR="/Applications/Xcode_ЦелеваяВерсия.app/Contents/Developer" \
xcodebuild -version

Имя приложения в пути должно соответствовать фактическому размещению установленного Xcode. Проверьте вывод в той же оболочке, из которой запускается CI: переменная окружения, установленная в интерактивном терминале, не обязательно попадёт в задачу автоматизации.

Должна ли единственная сборочная машина обновиться уже сейчас

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

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

Решение можно принять по следующему списку. Отмечайте пункт только после проверки на соответствующей среде:

• [ ] Известно, где создаётся каждый архив, который команда может отправить в App Store Connect.
• [ ] Зафиксированы macOS, архитектура, выбранный Xcode и доступные SDK на каждой сборочной среде.
• [ ] SDK сборки, deployment target и требование к версии Xcode записаны как отдельные параметры.
• [ ] Представительный проект проходит Archive на целевом инструментальном наборе.
• [ ] Проверено подписание релизной конфигурации, а не только компиляция Debug.
• [ ] Сценарии CI и локального выпуска используют ожидаемый Xcode и не зависят от случайных глобальных настроек.
• [ ] Сборка загружается в App Store Connect, а команда умеет найти её после обработки.
• [ ] До переключения определены ответственный за миграцию и процедура возврата к прежней среде.

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

Финальная проверка: архив, загрузка и статус в App Store Connect

До принятия нового процесса проверьте не только сообщение «Build Succeeded». Оно подтверждает выполнение сборки, но не доказывает, что получен нужный архив, использована ожидаемая конфигурация подписи и завершена загрузка. После загрузки отдельно проверьте доступность сборки в App Store Connect и её статус обработки.

Запишите для каждого тестового релиза четыре факта:

1. Какая версия Xcode фактически выполняла Archive и какой SDK был выбран для сборки.
2. Какой проект, схема и конфигурация использовались, а также какой deployment target задан.
3. Завершилось ли подписание архива ожидаемыми сертификатом и профилем подготовки.
4. Появилась ли сборка в App Store Connect и можно ли выбрать её для дальнейшей отправки.

Apple отдельно документирует ресурс Build в App Store Connect API и выбор сборки для отправки на проверку. Используйте эти этапы как разные контрольные точки: успешная команда xcodebuild archive, завершённая загрузка и появление доступной сборки — не одно и то же доказательство.

Для собственного сценария архивирования сохраните воспроизводимую команду, адаптировав путь, схему и каталог под проект:

xcodebuild \
  -workspace "Путь/к/Проекту.xcworkspace" \
  -scheme "НазваниеСхемы" \
  -configuration "Release" \
  -destination "generic/platform=iOS" \
  -archivePath "Путь/к/выходному/Приложению.xcarchive" \
  archive

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

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

Как проверить удалённый Mac до передачи ему релизной сборки

Удалённый Mac может быть полезен как временная площадка для проверки целевого Xcode, особенно если локальная машина не подходит по требованиям к macOS или команде нужно сохранить основной производственный хост без изменений. Но удалённый доступ сам по себе не подтверждает совместимость: конкретную связку ОС, Xcode, проекта, подписи и загрузки всё равно нужно проверить на выбранной среде.

До того как переносить туда выпуск, проверьте последовательно:

• есть ли у среды версия macOS, совместимая с целевым Xcode согласно официальной документации;
• можно ли установить и выбрать нужный Xcode, а также получить ожидаемый вывод xcodebuild -version и xcodebuild -showsdks;
• доступны ли терминал, рабочие файлы проекта и нужный канал доступа — например, SSH, VNC или веб-консоль;
• проходит ли Archive на копии или тестовой ветке проекта;
• можно ли организовать безопасный доступ к сертификатам и профилям без хранения секретов в открытом виде;
• доступна ли сборка после загрузки в App Store Connect и можно ли подтвердить её состояние.

Для оценки способа подключения можно изучить описание удалённого Mac, а вопросы по доступу и использованию сверить с центром помощи NodeMini. Эти страницы дают информацию о сервисе, но не заменяют проверку конкретного проекта и целевого Xcode. Фактическую совместимость следует считать установленной только после теста в выбранном окружении.

Практический итог на 2026 год

Требование к iOS 27 SDK и iPadOS 27 SDK начинает действовать с апреля 2027 года; оно не означает, что минимальная поддерживаемая версия приложения автоматически должна стать iOS 27. В 2026 году целесообразно зафиксировать текущий маршрут выпуска, проверить проект на целевом Xcode и macOS, испытать подпись и загрузку, а затем переключать сборочную машину с сохранённой возможностью отката. Это особенно важно, если старый Mac остаётся единственной средой для срочных исправлений.

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

Если локальная машина не подходит для теста, сначала оцените возможность провести проверку в арендуемой среде, не передавая туда единственный производственный процесс до подтверждения результата. Информацию о вариантах доступа и аренды Mac можно посмотреть на странице удалённых Mac NodeMini; окончательное решение о переносе принимайте после проверки именно своего Archive, подписи и загрузки.