Как подготовить среду iPhone Duo для Xcode 27.1? Руководство по двухконтурному CI на 2026 год

По данным официальной страницы Apple для разработчиков iPhone Duo, поддержка iPhone Duo, iOS 27.1 и Xcode 27.1 должна появиться в отдельной будущей версии инструментов, а beta ожидается позже в сентябре 2026 года. Поэтому победитель уже сейчас очевиден: стабильный контур Xcode 27 нужно оставить без изменений, а среду iPhone Duo для Xcode 27.1 создать отдельно. Если вам нужна только краткая адаптация или не хватает Mac-ресурсов, временно добавьте независимый Mac, а не заменяйте всю рабочую инфраструктуру.

Эта инструкция рассчитана на три группы:

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

Последнее обновление: 17 сентября 2026 года. Факты сверены с страницей подготовки iPhone Duo, системными требованиями Xcode и документацией Apple по тестированию beta-систем. До публикации beta конкретные требования к macOS, поведение симулятора и состав установочного пакета нельзя считать проверенными.

До публикации beta: заморозка стабильного контура

Главная ошибка — начать с установки нового Xcode. Сначала зафиксируйте состояние, которое сейчас выпускает приложение для iPhone 18 Pro.

Запишите в одном version lock-файле:

• точную версию Xcode 27 и активный путь к xcode-select;
• версию macOS на сборочном Mac;
• SDK и deployment target;
• commit приложения и хэш файла зависимостей;
• версии Swift Package Manager, CocoaPods или другого менеджера пакетов, если они используются;
• идентификаторы signing team, provisioning profiles и сертификаты;
• команды сборки, тестирования и архивации;
• название test plan;
• способ проверки .app, .ipa или архива;
• контрольные значения для ключевых артефактов.

Сам файл не должен содержать закрытые ключи. Храните только имена профилей, идентификаторы и ссылки на контролируемое хранилище секретов.

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

export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"

xcodebuild -version
xcodebuild -showsdks
xcodebuild \
  -workspace App.xcworkspace \
  -scheme App \
  -configuration Release \
  -destination 'generic/platform=iOS' \
  archive \
  -archivePath build/stable/App.xcarchive

Команду нужно адаптировать к проекту. Не копируйте параметры из примера без сверки с вашей схемой. Apple отдельно описывает назначение Command Line Tools и выбор активного developer directory в документации по инструментам командной строки.

Сохраните успешный архив до подключения проверочного контура. Зафиксируйте не только результат, но и логи: время начала, commit, версии инструментов, warnings, тестовые отчёты и параметры агента. Это позволит отличить изменение проекта от изменения Xcode.

Что именно создаёт риск для проекта

Тестирование iPhone Duo не обязано менять существующий проект. Но общая среда делает это возможным. Наиболее частые источники загрязнения — четыре.

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

Во-вторых, общий кэш зависимостей. Изменившийся SDK или пакет может попасть в стабильную сборку через общий каталог. Особенно опасны скрипты, которые очищают или перегенерируют кэш без привязки к версии инструмента.

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

В-четвёртых, глобальные настройки. К ним относятся активный xcode-select, переменные окружения, симуляторы, Ruby или Swift toolchain, настройки SSH и локальные конфигурационные файлы. Их изменение на единственном Mac способно остановить обычный выпуск даже до первой компиляции.

Отдельно учитывайте системные требования. Apple может изменить минимальную версию macOS или перечень поддерживаемых устройств для Xcode 27.1. Поэтому до официального пакета нельзя объявлять конкретный Mac совместимым только на основании слухов или названия модели. Проверяйте актуальную страницу системных требований Xcode в день открытия beta, RC или релиза.

Две линии и границы ответственности

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

Контур	Назначение	Что разрешено менять	Что должно остаться неизменным
Стабильный Xcode 27	Pull request, выпуск и текущая регрессия iPhone 18 Pro	Только плановые изменения проекта	SDK, сертификаты, базовые кэши и правила релиза
Проверочный Xcode 27.1	Подготовка iPhone Duo, новый SDK, симулятор и beta-проверки	Xcode, симуляторы, тестовые кэши и отдельные переменные	Production-секреты, стабильный агент и основной маршрут merge

На одном Mac оба контура возможны, но отдельный Mac безопаснее. Совместная установка допустима, если разные .app имеют разные пути, DEVELOPER_DIR задаётся в каждой задаче, а каталоги DerivedData и кэша привязаны к контуру.

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

export DEVELOPER_DIR="/Applications/Xcode-27.1-beta.app/Contents/Developer"
export DERIVED_DATA_PATH="$HOME/Library/Developer/Xcode/DerivedData-duo-beta"
export PACKAGE_CACHE_PATH="$HOME/Library/Caches/com.apple.dt.Xcode-duo-beta"

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

Наиболее безопасные варианты по условиям:

• Один Mac, ограниченный бюджет. Установите Xcode 27.1 отдельно, но не делайте его системным по умолчанию. Стабильные job должны передавать DEVELOPER_DIR явно.
• Один Mac, ежедневные релизы. Используйте отдельный системный том или независимый пользовательский контур, если это согласуется с политикой вашей компании.
• Критичный production CI. Не меняйте существующий агент. Добавьте временный независимый Mac для beta-проверок.
• Короткий период адаптации. Аренда отдельного Mac на период проверки обычно логичнее полной замены локальной машины: после стабилизации вы сможете удалить экспериментальный маршрут.

При установке дополнительных компонентов следуйте официальной инструкции Apple по компонентам Xcode. Не запускайте неизвестные скрипты установки от имени администратора и не переносите автоматически ключи из production-связки.

Первый час после появления Xcode 27.1

Первый запуск должен быть коротким и диагностическим. Не начинайте с полной UI-матрицы. Вам нужно доказать, что новый агент способен выполнить базовый цикл.

Шаг 1. Проверка инструмента

Проверьте версию, активные SDK, доступность симулятора и права пользователя:

xcodebuild -version
xcodebuild -showsdks
xcrun simctl list devices available
security find-identity -v -p codesigning

Последнюю команду запускайте только в разрешённом контуре. Вы не должны публиковать её вывод вместе с секретами или внутренними идентификаторами.

Шаг 2. Получение исходного кода

Используйте тот же commit, который уже успешно собрался стабильным Xcode 27. Не обновляйте одновременно исходный код, lock-файл и Xcode. Иначе у вас будет несколько возможных причин изменения результата.

Проверьте доступ к репозиторию, SSH-ключу и внутреннему хранилищу зависимостей. Если пакет не разрешается, сначала классифицируйте ошибку как проблему доступа или сети, а не как дефект Xcode 27.1.

Шаг 3. Чистое разрешение зависимостей

Соберите проект с отдельным DerivedData. Не удаляйте стабильный кэш в попытке «починить» beta-агент. Для первого запуска важна воспроизводимость: зафиксируйте lock-файл, источники пакетов и результат разрешения.

Шаг 4. Компиляция

Соберите Debug и Release, если оба режима участвуют в CI. Затем выполните архивирование. Сравните не только exit code, но и warnings, список linked frameworks, подпись и размер артефактов. Без разрешённой методики измерения нельзя объявлять такую сборку быстрее или медленнее.

Шаг 5. Модульные тесты

Запустите общий test plan на том же commit. Если он не проходит, сохраните .xcresult и полный лог. Apple рекомендует организовывать тесты через test plans, чтобы разделять наборы и получать более управляемую обратную связь; соответствующая схема описана в документации по организации тестов.

Шаг 6. Архив и проверка подписи

Сформируйте архив и проверьте, что он соответствует ожидаемой конфигурации. Для release-сборки применяйте отдельный шаг валидации, а не смешивайте его с диагностикой симулятора. Рекомендации Apple по проверке release build приведены в документации о тестировании выпуска.

После этих шагов разделите сбои на три категории:

1. Проблема проекта — тот же commit не собирается и в стабильном контуре.
2. Проблема beta-инструмента — стабильная линия проходит, а Xcode 27.1 падает при одинаковых входных данных.
3. Проблема окружения — ошибка исчезает после исправления пути, доступа, кэша или signing-настроек.

Такой журнал важнее общего статуса «beta работает». Он формирует основание для решения о включении канала в CI.

CI-маршруты до появления симулятора

Стабильная линия должна продолжать обслуживать pull request и официальный выпуск. Не ставьте адаптацию iPhone Duo блокирующим условием для каждого изменения приложения, пока проверочный контур не доказал свою повторяемость.

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

• Блокирующие. Сборка основного приложения, обязательные модульные тесты, проверка подписи и существующая регрессия для iPhone 18 Pro.
• Проверочные. Сборка Xcode 27.1 на том же commit, разрешение зависимостей и общий набор unit-тестов.
• Неблокирующие. Первые тесты интерфейса iPhone Duo, экспериментальные сценарии ориентации и отчёты о поведении beta-симулятора.

В CI удобно использовать отдельные job names:

build-stable-ios18
test-stable-ios18
build-duo-xcode271
test-duo-layout
report-duo-simulator

Стабильный job не должен ждать завершения экспериментального. Если проверочный агент занят, pull request всё равно должен получить обязательный результат основной линии.

Сохраните в каждом отчёте:

• commit и branch;
• версию Xcode;
• версию macOS;
• destination;
• имя test plan;
• cache key;
• статус подписи;
• причину повторного запуска;
• ссылку на .xcresult.

Тестовые планы позволяют вынести общие тесты и специальные проверки в отдельные наборы. Это снижает риск, что экспериментальная матрица замедлит выпуск или скроет реальную ошибку в большом отчёте.

Симулятор iPhone Duo и границы его пользы

После того как симулятор iPhone Duo станет доступен, не ограничивайтесь добавлением нового имени устройства в список destinations. Для складного форм-фактора важны состояния.

Минимальный набор проверок должен охватывать:

• запуск на внешнем экране;
• переход на внутренний экран;
• изменение ориентации;
• переход между портретным и альбомным режимами;
• восстановление состояния после смены конфигурации;
• открытие и закрытие модальных экранов;
• изменение safe area;
• продолжение сетевой операции после изменения состояния;
• сохранение текста, позиции прокрутки и выбранного элемента;
• переход приложения в фон и возврат на другой конфигурации.

Проверяйте не только snapshot. Добавьте assertions для размеров контейнера, доступности элементов, состояния навигации и повторного создания view controller. Сбой layout-теста должен показывать исходную конфигурацию, ориентацию и состояние приложения.

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

Распределение между локальным Mac и CI должно быть таким:

• локально — разработка, быстрый просмотр и отладка одного сценария;
• в CI — повторяемые проверки размеров, ориентаций, восстановления состояния и сохранения артефактов;
• на реальном iPhone Duo — камера, жесты, физическая механика и подтверждение поведения перед выпуском.

Для beta-операционной системы используйте отдельные правила допуска. Apple предупреждает о специфике тестирования beta-систем в соответствующей документации. Пока beta не открыта официально, не утверждайте, что конкретная команда, destination или поведение симулятора уже проверены.

Первая неделя: очередь, сбои и расширение

После первого успешного запуска не объединяйте линии автоматически. Наблюдайте за ними в течение рабочей недели и фиксируйте четыре показателя:

• время ожидания job;
• число конфликтов за Mac-агент;
• доля попаданий в кэш;
• количество повторных запусков и их причины.

Не переводите наблюдения в неподтверждённые проценты без единой методики измерения. Сравнивайте одинаковые commit, одинаковые test plans и одинаковые ограничения очереди.

Оставляйте два контура, если:

• iPhone 18 Pro требует регулярного выпуска;
• beta-агент периодически меняет поведение;
• тесты iPhone Duo длиннее обычной регрессии;
• команде нужен быстрый откат без переустановки;
• один Mac создаёт конфликт между релизом и экспериментом.

Рассматривайте объединение инструментов только после того, как Xcode 27.1 станет подтверждённой частью рабочего процесса, все обязательные тесты будут воспроизводимыми, а правила отката — проверенными. Даже тогда не объединяйте кэши и права автоматически.

Продлевайте изоляцию, если причина сбоя не определена. Временный дополнительный Mac оправдан, когда проверочный маршрут нужен на короткий период, а production-агент уже загружен. Полная замена локального оборудования не решает проблему неправильного разделения секретов, кэшей и обязанностей job.

Чек-лист готовности к откату

Перед включением Xcode 27.1 в командный процесс отметьте каждый пункт:

• [ ] Стабильный Xcode 27 запускается тем же способом, что и до эксперимента.
• [ ] Есть сохранённый архив успешной версии для iPhone 18 Pro.
• [ ] Зафиксированы commit, SDK, macOS, зависимости и test plan.
• [ ] Путь DEVELOPER_DIR задаётся явно.
• [ ] DerivedData и кэши разделены по контурам.
• [ ] Тестовый агент не имеет лишних production-прав.
• [ ] Доступны команды очистки только beta-каталогов.
• [ ] Сохранены логи и .xcresult.
• [ ] CI может отключить duo-job без изменения стабильной линии.
• [ ] Проверены сборка, unit-тесты, архив и подпись.
• [ ] Для симулятора определены автоматизируемые сценарии.
• [ ] Составлен список проверок для реального iPhone Duo.
• [ ] Есть владелец решения о возврате, расширении или объединении маршрутов.

Быстрый откат должен выглядеть как переключение маршрута, а не как аварийная переустановка всей машины:

export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"
rm -rf "$HOME/Library/Developer/Xcode/DerivedData-duo-beta"

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

Частые вопросы

Что можно подготовить до выхода Xcode 27.1?
До публикации Xcode 27.1 вы можете заморозить текущую сборочную линию, описать версии SDK, сертификатов и зависимостей, подготовить отдельный системный том или Mac, а также создать отдельные каталоги DerivedData и кэшей. Команды установки и проверки нужно выполнять только после сверки с официальными системными требованиями и release notes Apple.

Может ли тестирование iPhone Duo повредить существующий проект Xcode?
Само наличие отдельной версии Xcode не должно менять проект, но риск появляется при общих каталогах кэша, связке ключей, сертификатах, пакетах и настройках CI. Поэтому стабильный Xcode 27 оставляют основным, а Xcode 27.1 запускают с отдельными путями, правами и переменными окружения. Перед экспериментом сохраните проверенный архив.

Можно ли держать Xcode 27 и 27.1 на одном Mac?
Да, при условии, что вы не используете одну рабочую среду без разграничения. Приложения можно разделить по путям, а DerivedData, Swift Package Manager, CocoaPods и временные артефакты — по каталогам. Для подписывания сборок лучше применять отдельный CI-агент или строго ограниченный профиль доступа, чтобы тестовый контур не изменил production-настройки.

Где лучше запускать симулятор iPhone Duo — локально или в CI?
Локальный Mac удобнее для первичной проверки интерфейса и быстрых экспериментов. Отдельный CI подходит для повторяемых тестов размеров, ориентаций, восстановления состояния и регрессий. Переключение экранов, физические ощущения от шарнира и особенности камеры нельзя считать полностью проверенными по симулятору — для них потребуется реальное устройство после его появления.

Как быстро откатиться после сбоя beta-версии Xcode?
Остановите тестовый маршрут, верните стабильный Xcode 27 в качестве DEVELOPER_DIR, очистите только артефакты проверочного контура и повторите сборку тем же commit. Не удаляйте сразу общие сертификаты и зависимости. Если ошибка исчезла на стабильной линии, зафиксируйте её как проблему beta или среды, а затем приложите логи, версии SDK и параметры агента к внутреннему отчёту.

Если ваша текущая схема — один общий Mac, общий кэш и ручное переключение Xcode, у неё есть три реальных недостатка: beta может занять ресурс в момент релиза, ошибочный xcode-select способен направить production job не в тот SDK, а общие сертификаты и DerivedData усложняют доказательство причины сбоя. После заморозки стабильного контура разумнее оценить срок адаптации и временно арендовать независимый Mac через vmzig, чем сразу перестраивать всю локальную инфраструктуру. Это особенно оправдано для короткого тестового периода; для постоянной тяжёлой нагрузки или требований к физическим интерфейсам собственный Mac всё равно может быть рациональнее.

Частые вопросы

Что можно подготовить до выхода Xcode 27.1?

До публикации Xcode 27.1 вы можете заморозить текущую сборочную линию, описать версии SDK, сертификатов и зависимостей, подготовить отдельный системный том или Mac, а также создать отдельные каталоги DerivedData и кэшей. Команды установки и проверки нужно выполнять только после сверки с официальными системными требованиями и release notes Apple.

Может ли тестирование iPhone Duo повредить существующий проект Xcode?

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

Можно ли держать Xcode 27 и 27.1 на одном Mac?

Да, при условии, что вы не используете одну рабочую среду без разграничения. Приложения можно разделить по путям, а DerivedData, Swift Package Manager, CocoaPods и временные артефакты — по каталогам. Для подписывания сборок лучше применять отдельный CI-агент или строго ограниченный профиль доступа, чтобы тестовый контур не изменил production-настройки.

Где лучше запускать симулятор iPhone Duo — локально или в CI?

Локальный Mac удобнее для первичной проверки интерфейса и быстрых экспериментов. Отдельный CI подходит для повторяемых тестов размеров, ориентаций, восстановления состояния и регрессий. Переключение экранов, физические ощущения от шарнира и особенности камеры нельзя считать полностью проверенными по симулятору — для них потребуется реальное устройство после его появления.

Как быстро откатиться после сбоя beta-версии Xcode?

Остановите тестовый маршрут, верните стабильный Xcode 27 в качестве DEVELOPER_DIR, очистите только артефакты проверочного контура и повторите сборку тем же commit. Не удаляйте сразу общие сертификаты и зависимости. Если ошибка исчезла на стабильной линии, зафиксируйте её как проблему beta или среды, а затем приложите логи, версии SDK и параметры агента к внутреннему отчёту.