По текущей таблице системных требований Apple Xcode 27 поддерживает deployment target iOS 15–27. Следовательно, Xcode 27 не требует автоматически назначать iOS 27 минимальной версией приложения. Проверьте deployment target, доступность API и результат тестов на поддерживаемых системах. Отдельно подготовьтесь к правилу App Store: начиная с апреля 2027 года загружаемые приложения должны использовать iOS и iPadOS 27 SDK или новее. Это требование к SDK сборки, а не к минимальной версии iOS, на которой запускается приложение. Apple указывает срок и требование к SDK отдельно.
Материал предназначен разработчикам, которые поддерживают старые версии iOS и решают, нужно ли менять deployment target.
Он также пригодится тем, кто проверяет новый SDK на удалённом Mac или в CI, не затрагивая текущий выпуск.
Небольшим командам с несколькими приложениями он поможет определить миграцию отдельно для каждого проекта.
Последнее обновление: 25 сентября 2026 года. Дата требования и диапазон deployment target сверены с объявлениями Apple о загрузке приложений и таблицей системных требований Xcode. Эти страницы могут обновляться. Перед выпуском проверьте актуальные сведения ещё раз.
[ SECTION_01 ] SDK сборки и минимальная iOS отвечают на разные вопросы
SDK — это набор интерфейсов и средств разработки, с которыми собирается приложение. Минимальная версия iOS, или deployment target, задаёт нижнюю границу системы, для которой предназначен проект. Поэтому применение iOS 27 SDK само по себе не означает, что приложение сможет запускаться только на iOS 27.
У этих параметров разные последствия. SDK определяет доступные при сборке интерфейсы и инструменты. Deployment target задаёт заявленный диапазон поддержки и влияет на проверки совместимости. Система, на которой приложение запущено во время тестирования, показывает, что именно команда проверила. Ни один из этих пунктов не заменяет остальные.
Отсюда возникают типичные ошибки планирования:
- Требование к загрузке принимают за требование к совместимости. Использование нового SDK не устанавливает автоматически новый минимальный deployment target.
- Настройку проекта принимают за доказательство работоспособности. Низкое значение deployment target не гарантирует, что используемые API и сторонние зависимости поддерживают старую систему.
- Успешную сборку считают завершённой проверкой. Компилятор может собрать приложение, но это не подтверждает работу функций и интерфейса на каждом устройстве.
- Локальный результат переносят на CI без повторной проверки. На удалённом узле могут отличаться Xcode, SDK, настройки подписи и дополнительные компоненты.
- Для всех приложений выбирают одну дату миграции. У проектов разные зависимости, графики выпуска и обязательства перед пользователями.
Объявленное Apple требование относится к загрузкам приложений для iOS и iPadOS: начиная с апреля 2027 года необходимо использовать iOS и iPadOS 27 SDK или более новый. В текущей таблице требований Xcode 27 при этом указан диапазон deployment target от iOS 15 до iOS 27. Это разные характеристики. По ним нельзя заключить, что каждый стабильный выпуск Xcode 27 одинаково ведёт себя во всех проектах или что любой проект уже проверен на этом диапазоне систем.
[ SECTION_02 ] Сначала определите сценарий конкретного приложения
Приложение уже поддерживает старые системы
Если текущая версия проходит сборку и тесты на старых iOS, не повышайте deployment target только из-за требования к SDK. Сначала зафиксируйте фактическое значение для каждой цели и проверьте ограничения библиотек. Если зависимость перестала поддерживать старую систему, решение может определяться именно ею, а не новым Xcode.
Проверяйте не только основную цель приложения. В проекте могут быть расширения, виджеты и отдельные тестовые цели. У них бывают собственные настройки. Apple описывает параметры настройки целей в документации по конфигурации нового target. Сверьте настройки тех целей, которые действительно участвуют в сборке и выпуске.
В приложение добавляют новые API
Новая функция может использовать API, недоступный на части поддерживаемых систем. Это не всегда требует повышать минимальную iOS для всего приложения. Если для функции есть более ранняя реализация или её можно отключить на старых системах, предусмотрите альтернативный путь и проверьте его отдельно.
Проверьте доступность API на этапе разработки и добавьте runtime-проверку там, где поведение зависит от версии системы. Apple объясняет, как обозначать доступность API и запускать код с учётом версии системы. Эти средства помогают безопасно вызывать API, но не доказывают, что приложение корректно работает на реальном устройстве.
Для каждого нового вызова стоит определить конкретный сценарий отказа. Что увидит пользователь, если функция недоступна? Есть ли для старой системы запасной путь? Не обращается ли код к новому API раньше, чем выполняется проверка версии? Ответы на эти вопросы помогают сохранить поддержку старых систем без маскировки ошибок за одним лишь низким deployment target.
Готовится новая версия для App Store
Если команда пока выпускает приложение через стабильную цепочку сборки, отделите сохранение поддержки старых iOS от подготовки к новому правилу загрузки. Срок миграции зависит от графика релиза, зависимостей и возможности повторить сборку в проверенной среде. Не заменяйте единственный производственный инструмент, пока новый вариант не прошёл проверку на копии проекта или отдельном узле.
Сопоставьте настройки сборки с справочником Build Settings, затем сохраните журналы новой сборки. Подтверждением готовности служит не только выбранный SDK. Нужны успешные этапы, которыми пользуется ваш выпускной процесс: сборка, тесты, архивирование и подпись. Если результат отличается от ожидаемого, выясните, относится ли ошибка к deployment target, API, зависимости или среде.
Поддерживается несколько приложений или веток
Оценивайте каждый проект отдельно. Для одного может быть достаточно оставить прежнюю минимальную iOS и проверить новый SDK. Другому понадобится замена зависимости. Для третьего команда может решить повысить deployment target как отдельное продуктовое решение, например, если дальнейшая проверка старой системы стала неоправданно затратной.
Не переносите вывод одного проекта на остальные без проверки. Записывайте для каждого приложения значение deployment target, используемый SDK, версии зависимостей, проверенные системы и условие следующего пересмотра. Такая запись помогает понять при срочном выпуске, почему проект сохраняет старую поддержку или почему её пришлось прекратить.
[ SECTION_03 ] Проверка перед решением о миграции
Проверяйте проект в том окружении, которое должно собирать выпуск. Если приложение разрабатывается локально, но публикуется с удалённого Mac, окончательное подтверждение должно включать удалённую среду. Действуйте последовательно.
Шаг первый: зафиксируйте исходное состояние. Запишите deployment target для каждой цели, активную схему, выбранный Xcode и используемые зависимости. Не меняйте одновременно SDK, минимальную версию iOS и версии библиотек. Иначе при ошибке будет сложнее определить её причину.
Шаг второй: проверьте настройки проекта. Откройте Build Settings приложения и связанных целей. Найдите iOS Deployment Target и проверьте, не переопределяется ли значение конфигурацией сборки. Сверьте смысл параметра со справочником настроек Xcode. Версию SDK фиксируйте по фактической среде сборки, а не по названию ветки или комментарию в проекте.
Шаг третий: проверьте новые API. Найдите вызовы, добавленные при переходе на iOS 27 SDK. Для каждого выясните, доступен ли он на минимальной поддерживаемой системе и есть ли приемлемая замена. Защитите вызов проверкой доступности или оставьте альтернативное поведение. Убедитесь, что старый путь тоже проверяется.
Шаг четвёртый: проверьте зависимости и цели. Сверьте минимальные системные требования библиотек, расширений и внутренних пакетов. Просмотрите настройки не только основного приложения, но и целей, участвующих в выпуске. Обновление одной зависимости может ограничить поддержку старой системы раньше, чем изменение SDK.
Шаг пятый: соберите и протестируйте целевые варианты. Выполните чистую сборку с выбранным Xcode, затем запустите тесты на системах, которые входят в заявленную поддержку. Симулятор полезен для ряда проверок, но не заменяет все тесты на целевых устройствах. Зафиксируйте, какие системы и пользовательские сценарии действительно проверены.
Шаг шестой: проверьте выпускной процесс. Повторите архивирование и подпись в том же удалённом окружении или CI, из которого планируется отправлять релиз. Локального Build недостаточно. Сохраните журнал архивирования, результат подписи и сведения о выбранном SDK. Не включайте секреты подписи в общедоступные артефакты и логи.
Шаг седьмой: задайте условия повторной проверки. Вернитесь к решению, если Apple изменит требования к загрузке или системную таблицу, выйдет новый стабильный Xcode либо обновится зависимость, влияющая на поддержку. Перед переходом также проверяйте официальные заметки к выпуску Xcode 27.
Для удалённой сборки важна воспроизводимость на самом узле. Наличие нужного Xcode в описании среды не гарантирует, что проект соберётся, пройдёт тесты и подпишет архив. Выполните фактический запуск проекта. Проверяйте каждый проект отдельно: подтверждение для одного приложения не доказывает готовность остальных. Если требуется оценить отдельную удалённую среду для такого контура, информация о сервисе NOVAKVM поможет понять, подходит ли этот формат для проверки инструментария и выпуска.
[ SECTION_04 ] Решение по условиям, а не по номеру SDK
Используйте этот список как инструмент выбора. Отметьте подходящие условия для каждого приложения, затем примените соответствующую ветку решения.
- [ ] Оставить минимальную iOS без изменений. Отметьте этот вариант, если проект и зависимости поддерживают текущий deployment target, новые API имеют безопасный путь для старых систем, а сборка и тесты успешны. Требование к SDK само по себе не является основанием отказываться от старых пользователей.
- [ ] Запустить параллельную проверку. Выбирайте этот вариант, если срок загрузки уже влияет на план выпуска, но не проверена хотя бы одна зависимость, подпись или удалённая сборка. Сохраните действующий производственный процесс и подтвердите новый SDK отдельно. Не переключайте единственный путь выпуска до получения результатов.
- [ ] Рассмотреть повышение deployment target. Этот вариант уместен, если критическая зависимость прекратила поддержку старой системы, новой функции нет приемлемой альтернативы или команда осознанно прекращает сопровождение старых устройств. Учитывайте влияние на пользователей и график релиза; не выдавайте это решение за требование к SDK.
- [ ] Отложить переключение производственной сборки. Отметьте его, если новая среда не прошла архивирование, подпись или тесты на целевых системах. Исправьте конкретный блокирующий этап, повторите проверку и сохраните уже подтверждённый путь.
- [ ] Оценивать приложения отдельно. Если проекты отличаются зависимостями и планами выпуска, принимайте решения по каждому. Общая дата обновления инструмента не означает, что всем проектам нужно одновременно менять минимальную iOS.
Готовность удобно оценивать по трём независимым подтверждениям: срок и правило загрузки проверены на официальной странице, параметры проекта получены из фактической сборки, совместимость проверена на системах, поддержку которых команда обещает. Если какого-то подтверждения нет, итоговое решение остаётся предварительным.
Разделяйте совместимость приложения и готовность конвейера. Приложение может оставаться совместимым со старой iOS, хотя удалённая среда ещё не готова собирать его новым SDK. Возможна и обратная ситуация: новая цепочка создала архив, но поведение приложения на старых системах не проверено. В таком случае решение должно устранять именно обнаруженный риск, а не сводиться к общему требованию «обновить всё».
[ SECTION_05 ] Частые вопросы о старых версиях iOS
Обязательно ли задавать iOS 27 как минимальную систему для Xcode 27?
Нет. В текущей таблице системных требований Apple для Xcode 27 указан диапазон deployment target iOS 15–27. Он показывает заявленный диапазон настройки минимальной системы, но не подтверждает совместимость конкретного приложения со всеми вариантами. Проверьте цели, зависимости и тесты проекта перед выпуском.
Можно ли сохранить поддержку старых устройств при сборке с iOS 27 SDK?
Да, если deployment target остаётся подходящим, зависимости совместимы, а вызовы новых API защищены проверками доступности или имеют альтернативный путь. Номер SDK не заменяет тестирование. Проверьте приложение на целевых системах и подтвердите работу старого сценария, а не только успешную компиляцию.
Изменит ли срок загрузки требования к уже опубликованному приложению?
Объявленное Apple правило относится к загружаемым приложениям: с апреля 2027 года потребуется iOS и iPadOS 27 SDK или новее. Из этого не следует, что опубликованная версия автоматически получит другой deployment target или перестанет запускаться на старых системах. Перед новой отправкой сверьте актуальное уведомление Apple.
Где увидеть минимальную версию и SDK, использованные в сборке?
Минимальную версию проверьте в Build Settings каждой цели, включая дополнительные цели выпуска. SDK подтвердите по активному Xcode и журналу сборки. Для удалённого CI или Mac выполните проверку непосредственно там: локальная настройка не подтверждает наличие нужных инструментов на узле и успешную подпись архива.
[ SECTION_06 ] Подготовьте выпуск, не отказываясь от старых систем без причины
Если сборка и тесты подтверждают поддержку старой iOS, оставьте deployment target без изменений и отдельно проверьте новый SDK. Если проект ещё не проходил выпуск через удалённую среду, переключайте его после проверки сборки, тестов, архивирования и подписи. Так требование к загрузке не станет необоснованной причиной удалять поддержку старых устройств.
Когда локального Mac недостаточно для независимой проверки или параллельного контура, удалённый Mac может подойти как отдельная среда сборки. Он не заменяет тесты приложения и не устраняет проблемы зависимостей. Сначала определите, нужен ли проекту временный узел для проверки нового Xcode или постоянная машина для регулярных выпусков. Информацию о доступной среде можно проверить на странице NOVAKVM с вариантами заказа Mac.
Собственная Mac-машина может быть практичнее при длительной непрерывной нагрузке или необходимости подключать физическое оборудование. Удалённая среда уместнее, когда нужно временно проверить новый SDK, разделить тестовый и производственный контуры или избежать покупки отдельного Mac только ради миграции. Сопоставьте срок использования, требования к физическим интерфейсам и необходимость постоянно держать узел под контролем. Тогда выбор будет следовать из задачи выпуска, а не только из номера нового SDK.
Частые вопросы
Нужно ли менять минимальную версию iOS, если проект собирается в Xcode 27?
Нет. Требование к SDK, которым собрана загружаемая версия приложения, и минимальная версия iOS, на которой оно запускается, — разные настройки. Проверьте deployment target проекта и ограничения его зависимостей, затем соберите и протестируйте приложение на поддерживаемой старой системе. Менять минимум следует только при подтверждённой несовместимости или отдельном продуктовом решении.
Можно ли выпускать приложение с iOS 27 SDK для старых устройств?
Сам по себе новый SDK не доказывает, что приложению нужна новая минимальная версия системы. Старые устройства могут оставаться в целевом диапазоне, если выбранный deployment target поддерживается, используемые API защищены проверками доступности, а зависимости совместимы. Результат подтверждают сборка и тесты на целевых системах, а не номер SDK.
Затронет ли новое требование App Store уже опубликованные приложения?
Объявленное требование относится к загрузке приложений: начиная с апреля 2027 года новые загрузки должны быть собраны с iOS и iPadOS 27 SDK или новее. Это не равнозначно автоматическому изменению минимальной версии уже опубликованного приложения. Перед очередным выпуском сверяйте актуальную страницу Apple и отдельно проверяйте собственные настройки проекта.
Где проверить SDK сборки и минимальную версию iOS в проекте?
В настройках цели проверьте поле iOS Deployment Target — оно задаёт минимальную систему для приложения. Версию используемого SDK определите по выбранному Xcode и фактическому журналу сборки. Затем сохраните настройки и результат сборки из того же удалённого или CI-окружения, где будет выполняться выпуск: локальная проверка не подтверждает готовность производственной среды.