Xcode 27 Beta vs Xcode 26: что ставить для сборки

Последнее обновление: 16 августа 2026 года. Версии и требования сверены с официальной таблицей системных требований Xcode, заметками о выпуске Xcode 27 Beta и требованиями App Store Connect.

Симптом: единственный Mac одновременно нужен для безошибочного релиза и проверки iOS 27, поэтому установка Beta поверх рабочей среды превращает сборочный сервер в экспериментальный стенд.
Самое быстрое решение: оставить Xcode 26.6 производственной версией, установить Xcode 27 Beta отдельно и переключать их только через явно заданные пути. Переход на Xcode 27 стоит рассматривать после RC или финального выпуска и только после проверки реального проекта, подписи, Archive, загрузки и отката.

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

Xcode 27 Beta vs Xcode 26: решение на 16 августа 2026 года

Сейчас рабочее разделение выглядит так:

• Xcode 26.6 — основной инструмент для производственной сборки, подписи, Archive и отправки версии, которая должна выйти в App Store.
• Xcode 27 Beta — отдельный контур для проверки iOS 27 SDK, новых API, поведения интерфейса, симулятора и потенциальных изменений компилятора.
• Xcode 27 Beta не следует назначать единственным инструментом релиза, даже если проект успешно собирается локально.

Apple указывает, что Xcode 27 Beta 4 работает с SDK iOS 27 и требует Mac на Apple silicon с macOS Tahoe 26.4 или новее. Xcode 26.6 поддерживает SDK iOS 26.5 и требует macOS Tahoe 26.2 или новее. Эти диапазоны нужно учитывать отдельно, потому что подходящая система для Beta не означает автоматическую совместимость всех старых скриптов и зависимостей. Официальная таблица требований Apple подтверждает различия между версиями.

Можно ли использовать Xcode 27 Beta для официальной публикации?
Для текущего производственного релиза мы не считаем Beta безопасной заменой Xcode 26.6. Apple отдельно сообщила, что сборки, созданные Xcode 27 Beta 4 с соответствующими beta SDK, можно отправлять во внутреннее и внешнее тестирование через TestFlight. Это не равно подтверждению, что Beta должна стать стандартом для отправки приложения конечным пользователям через App Store.

Кроме того, с 28 апреля 2026 года приложения, загружаемые в App Store Connect, должны быть собраны с Xcode 26 или новее и SDK соответствующей платформы 26 или новее. Поэтому Xcode 26.6 уже закрывает текущий минимальный порог для iOS-релизов, тогда как Xcode 27 Beta нужен прежде всего для будущего SDK и тестирования изменений. Страница Apple с текущими минимальными требованиями подтверждает это правило.

Изолированная установка двух версий

Можно ли держать Xcode 27 Beta и Xcode 26 на одной Mac-машине?
Да, при условии, что это два отдельных приложения, а командная строка каждый раз обращается к выбранному пути. Основная ошибка — не сам факт совместной установки, а использование одного глобального xcode-select для всех задач без фиксации исходного состояния.

Мы рекомендуем следующую схему:

1. Скачайте Xcode 26.6 и Xcode 27 Beta только из раздела Apple Developer.
2. Убедитесь, что стабильная версия уже запускается и собирает контрольный проект.
3. Поместите приложения в /Applications, используя разные имена, например Xcode-26.6.app и Xcode-27-Beta.app.
4. Не удаляйте стабильную версию ради освобождения места до завершения тестов.
5. Создайте отдельные каталоги DerivedData и, если это требуется инструменту, отдельные каталоги для кэша.
6. Проверьте, какая версия вызывается из терминала.

Для временного выбора версии используйте путь-заполнитель:

sudo xcode-select --switch /Applications/Xcode-26.6.app/Contents/Developer
xcodebuild -version

Для Beta:

sudo xcode-select --switch /Applications/Xcode-27-Beta.app/Contents/Developer
xcodebuild -version

Более безопасный вариант для CI — не менять глобальный выбор системы, а задать DEVELOPER_DIR только для одной команды:

DEVELOPER_DIR=/Applications/Xcode-26.6.app/Contents/Developer \
xcodebuild -workspace PROJECT_PLACEHOLDER.xcworkspace \
-scheme SCHEME_PLACEHOLDER \
-sdk iphoneos \
-configuration Release \
archive \
-archivePath /tmp/PROJECT_PLACEHOLDER.xcarchive

Для Beta меняется только значение DEVELOPER_DIR:

DEVELOPER_DIR=/Applications/Xcode-27-Beta.app/Contents/Developer \
xcodebuild -workspace PROJECT_PLACEHOLDER.xcworkspace \
-scheme SCHEME_PLACEHOLDER \
-sdk iphoneos \
-configuration Debug \
-derivedDataPath /tmp/deriveddata-xcode27

Не смешивайте DerivedData между версиями без необходимости. Компилятор, SDK и параметры генерации могут отличаться, поэтому общий кэш затрудняет диагностику и способен скрыть проблему до этапа Archive.

Сравнительная проверка одного проекта

Обе версии нужно сравнивать на одном commit, с одинаковыми переменными окружения и одинаковым набором зависимостей. Если Xcode 27 Beta проверяет новый API, это не означает, что производственная сборка должна использовать тот же SDK.

Разделите проверку на четыре уровня.

Восстановление зависимостей

Сначала выполните чистое восстановление:

bundle install
bundle exec pod install

Если проект использует только Swift Package Manager, зафиксируйте состояние пакетов и не разрешайте автоматическое обновление во время сравнения. Ошибка на этом этапе относится к зависимости или менеджеру пакетов, а не к компилятору.

Debug и unit tests

Для Xcode 26.6 проверьте базовую сборку и тесты. Для Xcode 27 Beta повторите те же действия отдельным каталогом DerivedData. Записывайте:

• предупреждения компилятора;
• ошибки Swift или Objective-C;
• проблемы с макросами и плагинами;
• сбои Simulator;
• различия в поведении API iOS 27.

Release Archive

Затем создайте Archive в обеих версиях, но с разными именами архивов:

ARCHIVE_PATH=/tmp/PROJECT_PLACEHOLDER-xcode26.xcarchive

и

ARCHIVE_PATH=/tmp/PROJECT_PLACEHOLDER-xcode27beta.xcarchive

На этом этапе отдельно проверяются компиляция, экспорт, provisioning profile и подпись. Успешный Debug не доказывает, что Release Archive будет принят системой загрузки.

Upload и обработка

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

Производственная неделя

В неделю официальной публикации не меняйте одновременно Xcode, macOS, зависимости и сертификаты. Зафиксируйте:

• Xcode 26.6;
• lock-файлы зависимостей;
• параметры схемы;
• способ подписи;
• путь к API-ключу или профиль аутентификации;
• команду Archive;
• команду загрузки;
• каталог резервного архива и журналов.

Порядок приёмки должен быть последовательным:

1. Чистое восстановление зависимостей.
2. Debug-сборка.
3. Unit tests.
4. Release Archive.
5. Export или подготовка к загрузке.
6. Подпись.
7. Upload.
8. Обработка в App Store Connect.
9. Проверка статуса сборки и метаданных.
10. Отправка выбранной версии на рассмотрение.

App Store Connect поддерживает загрузку несколькими способами, включая Xcode, Transporter и API. Для автоматизации это означает, что проблема может находиться не в Xcode, а в JWT, правах пользователя, Bundle ID или серверной команде загрузки. Официальное описание рабочего процесса App Store Connect рекомендует разделять загрузку, тестирование и отправку на рассмотрение.

Оценка вариантов для небольшой команды

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

Если действующий Mac уже занят сборками, отдельная среда позволяет не смешивать производственные ключи, DerivedData, симуляторы и команды fastlane. На практике это важнее, чем попытка сэкономить место удалением Xcode 26.6.