Как принять iOS App перед выпуском в Xcode 27? Чек-лист 2026

Проект собирается, Archive создан, но в App Store Connect нет нужной сборки или она не выбирается для отправки.

Быстрое решение: не считать релиз готовым после Archive — Xcode 27 iOS App перед выпуском должен пройти пять проверок: идентичность, артефакты, подпись, доставку и связь с App Store Connect.

Эта инструкция предназначена для трёх групп:

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

Последняя проверка материала выполнена 22 сентября 2026 года по записям Apple о выпусках Xcode, документации по дистрибуции и справке App Store Connect. После выхода новых сборок Xcode 27, изменения поведения Xcode 27.2 Beta или обновления статусов App Store Connect эти пункты необходимо перепроверить.

Сначала зафиксируйте критерий готовности релиза

У публикации нет одного универсального признака «готово». Успешный Archive подтверждает создание архива, но не доказывает, что IPA экспортирован, загружен, обработан платформой и доступен для TestFlight или отправки на проверку.

Полезно заранее зафиксировать состояние, доказательство и действие при остановке:

Эта граница соответствует логике Apple: дистрибуция начинается с подготовленного архива, но выбор сборки для отправки выполняется уже в App Store Connect. Подробные этапы описаны в документации Apple по дистрибуции приложения.

Проверьте личность приложения и версию

Первый показатель — не название проекта в Xcode, а значения, записанные в финальный Archive и экспортированный продукт. Настройки проекта могут быть изменены скриптом, конфигурацией схемы или параметрами CI, поэтому проверять только открытый файл проекта недостаточно.

Идентификаторы, которые должны совпасть

Нужно сопоставить:

• Bundle ID приложения;
• Target, из которого создан архив;
• Team и выбранную организацию разработчика;
• платформу и назначение сборки;
• version number;
• build string;
• имя и путь итогового Archive;
• запись приложения в App Store Connect.

Apple связывает загруженную сборку с записью приложения не по имени файла IPA. Важны Bundle ID, версия и Build string, поэтому именно эти значения следует извлекать из итогового продукта и сравнивать с карточкой приложения. Для нового приложения сначала должна существовать корректная запись с нужным Bundle ID; порядок создания записи описан в справке Apple по добавлению нового приложения.

Что проверить после создания Archive? Сначала откройте Organizer и зафиксируйте значения, отображаемые для выбранного архива. Затем сравните их с планом публикации и записью App Store Connect. Если версия соответствует уже созданной версии в App Store, новый архив обычно добавляется к ней как очередной Build; если требуется новая версия приложения, сначала создаётся соответствующая версия, а затем выбирается её сборка.

Не следует повторно отправлять уже использованный Build string в надежде, что платформа примет его как новый файл. Для новой попытки нужен новый номер сборки, а не только изменённое имя IPA. При ошибке идентичности сначала исправляются параметры Target или CI, после чего создаются новый Archive и новый экспорт. Перезапись старого файла на удалённом Mac проблему связи с App Store Connect не решает.

Минимальный лист проверки идентичности

• [ ] Bundle ID в Archive совпадает с целевой записью приложения.
• [ ] Archive создан из правильного Target, а не из вспомогательного или тестового Target.
• [ ] Team соответствует аккаунту, которому разрешена дистрибуция приложения.
• [ ] version number соответствует версии, выбранной в App Store Connect.
• [ ] build string ещё не использовался для этой записи.
• [ ] В финальном Archive нет неожиданного суффикса, тестового идентификатора или другой платформы.
• [ ] Для новой версии создана правильная карточка в App Store Connect.

Отделите настоящий дистрибутив от просто успешной сборки

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

Для приёмки необходимо сохранить связь между четырьмя объектами:

1. исходным коммитом или версией проекта;
2. Archive;
3. экспортированным IPA;
4. dSYM и журналом экспорта.

Если dSYM получен от другой сборки, диагностика падений после публикации станет ненадёжной. Если IPA экспортирован не из проверенного Archive, соответствие между тем, что было просмотрено в Organizer, и тем, что загружено, уже не доказано.

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

• схема использует Release или специально утверждённую дистрибуционную конфигурацию;
• архив не создан для симулятора;
• в продукте присутствуют ожидаемые entitlements;
• dSYM сохранён вместе с идентификатором архива;
• экспортная операция завершилась именно для нужного назначения;
• файл IPA не был заменён другим заданием после проверки.

Как подтвердить целостность Archive и IPA? Используйте один и тот же каталог артефактов для Archive, IPA, dSYM и журналов, а в CI сохраняйте идентификатор задания и commit hash. Для ручной работы достаточно не переименовывать файлы до завершения проверки и записать значения из Organizer в журнал релиза.

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

Подтвердите подпись, профиль и права автоматизации

Подпись нужно принимать не по наличию сертификата в Keychain, а по способности финального продукта пройти выбранный сценарий распространения. Сертификат может быть установлен, но не соответствовать Team, Bundle ID, entitlements или назначению профиля.

Проверка должна включать:

• signing identity, использованную для финального Archive;
• Provisioning Profile, выбранный при экспорте;
• Team ID и Bundle ID внутри профиля;
• entitlements приложения;
• доступ к сертификату из процесса CI;
• наличие dSYM и журнала подписи;
• отсутствие ручной подмены профиля после создания Archive.

Почему подпись в Xcode выглядит правильной, а загрузка всё равно завершается ошибкой? Потому что автоматическое управление подписью может выбрать другой профиль на этапе Archive или экспорта, а CI может работать с отдельным набором Keychain. Кроме того, локальная проверка проекта не показывает, какой именно профиль оказался внутри финального продукта.

Для удалённого Mac полезно разделить три секрета: доступ к машине, доступ к Keychain и токен либо учётные данные для загрузки. Нельзя считать, что наличие SSH-доступа автоматически даёт право подписывать и отправлять приложение. После переноса проекта следует повторить Archive в том же пользователе и сохранить безопасный журнал: без содержимого сертификатов, приватных ключей, токенов, Team ID, Bundle ID и внутренних путей.

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

Проверьте передачу и обработку в App Store Connect

Загрузка завершается не тогда, когда Transporter или командная строка вывели сообщение об успехе. Это лишь подтверждение передачи. Окончательный результат появляется после обработки на стороне App Store Connect.

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

• появилась ли сборка в правильной записи приложения;
• совпадают ли версия и Build string;
• соответствует ли время загрузки ожидаемому заданию;
• нет ли статуса Failed;
• не появились ли предупреждения, требующие действия;
• относится ли сборка к нужной платформе.

Как подтвердить правильную связь после загрузки? Сопоставьте три значения: Bundle ID в финальном Archive, version number и build string в App Store Connect. Затем проверьте, что запись находится под ожидаемой версией приложения, а не только в общем списке сборок. Справка Apple по просмотру сборок и метаданных используется именно для этой проверки.

Если состояние долго не меняется, нельзя делать вывод о готовности по одному времени ожидания: Apple не предоставляет здесь универсального обещания скорости обработки, а длительность зависит от текущего состояния платформы и содержимого сборки. Действия должны быть последовательными:

1. сохранить идентификатор загрузки и журнал;
2. проверить запись приложения, версию и Build string;
3. открыть сведения об ошибке или предупреждении;
4. не загружать повторно тот же Build string;
5. после исправления создать новый Build и повторить проверку.

Командный код возврата, сообщение Transporter и статус App Store Connect нужно хранить как разные доказательства. Это особенно важно при удалённом Mac: обрыв SSH или VNC не означает, что загрузка не состоялась, а закрытое окно не означает, что Processing завершён.

Проверьте TestFlight и возможность отправки

Сборка со статусом Complete ещё не всегда является готовой к отправке на проверку. После обработки могут оставаться сведения о соответствии требованиям, экспортном контроле, тестировании или данных версии приложения.

Можно ли сразу отправлять сборку в App Store после статуса Complete? Только если App Store Connect разрешает выбрать её в нужной версии и отсутствуют блокирующие сведения. Статус Complete подтверждает завершение обработки, но не заменяет проверку страницы версии, обязательных полей и связи с процессом отправки.

Для TestFlight выполните отдельный цикл:

• [ ] Откройте правильную запись приложения и нужную платформу.
• [ ] Убедитесь, что сборка находится под ожидаемой версией.
• [ ] Проверьте, что её можно выбрать для внутреннего или внешнего тестирования.
• [ ] Разберите Missing Compliance, если этот блок отображается.
• [ ] Убедитесь, что тестовая установка использует именно проверенный Build string.
• [ ] Проверьте запуск, первый экран, авторизацию и критический пользовательский путь.
• [ ] Перед отправкой ещё раз откройте форму выбора сборки.

Для подачи на проверку ориентируйтесь на инструкцию Apple по выбору сборки для отправки. Если сборка не выбирается, сначала проверяются обязательные сведения и соответствие версии, а не создаётся новый Archive вслепую.

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

Проведите приёмку удалённого Mac по границам ответственности

Удалённый Mac удобен как исполнитель повторяемых Archive, экспорта и загрузки, особенно когда локальная машина не должна постоянно хранить Xcode, профили и большой набор артефактов. Но он не заменяет App Store Connect как источник окончательного статуса.

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

• установлен ли утверждённый Xcode 27, а не случайная Beta-сборка;
• запускается ли нужная схема из командной строки;
• доступен ли Keychain процессу публикации;
• сохраняются ли Archive, IPA, dSYM и журналы;
• можно ли восстановить задачу после обрыва соединения;
• видит ли оператор, какой Build string был загружен;
• не остаются ли секреты в рабочих каталогах и логах;
• есть ли понятный способ удалить промежуточные артефакты после выпуска.

Xcode 27 и Xcode 27.2 Beta следует держать в разных рабочих контурах. Если релизная приёмка выполняется в официальной версии Xcode 27, результаты Beta нельзя использовать как доказательство стабильного поведения. Сведения о совместимости и изменениях следует сверять с актуальными заметками к выпуску Xcode, а не с названием установленного приложения.

Для небольшого проекта достаточно закрепить в журнале релиза версию Xcode, схему, commit hash, Bundle ID, version number, Build string, способ подписи, результат экспорта, идентификатор загрузки и ссылку на запись App Store Connect. Такой журнал помогает отличить ошибку проекта от ошибки удалённой среды и не повторять публикацию без изменения причины сбоя.

Если команде нужен отдельный Mac для этой процедуры, условия аренды удалённого Mac в RUVCLOUD стоит оценивать именно по доступу к Xcode, Keychain, SSH или VNC, сохранению артефактов и восстановлению задания, а не только по обещанию «облачной сборки». Для эпизодических выпусков рациональнее сначала сравнить расход по фактической частоте публикаций с вариантами тарифов RUVCLOUD.

Итоговая проверка перед передачей релиза

Перед тем как считать Xcode 27 iOS App принятым, выполните полный лист без пропуска уже знакомых пунктов:

• [ ] Финальный Archive создан из правильного Target и коммита.
• [ ] Bundle ID, Team, version number и build string записаны из фактического продукта.
• [ ] Версия и Build string соответствуют ожидаемой записи App Store Connect.
• [ ] Archive не является симуляторной или Debug-сборкой.
• [ ] IPA экспортирован из этого же Archive.
• [ ] Entitlements, профиль и signing identity относятся к одному сценарию дистрибуции.
• [ ] dSYM и журнал экспорта сохранены вместе с артефактами.
• [ ] Удалённый Mac или CI-процесс действительно имеет доступ к нужному Keychain.
• [ ] После загрузки проверены запись приложения, версия, Build string и статус Processing.
• [ ] Failed и предупреждения разобраны по журналу, а не скрыты повторной загрузкой.
• [ ] TestFlight видит нужную сборку, а тестовая установка выполнена.
• [ ] Missing Compliance и другие обязательные сведения не блокируют распространение.
• [ ] В App Store Connect сборку можно выбрать для отправки на проверку.

Главное различие между локальным Mac и постоянной удалённой средой — не в самом факте создания Archive. Локальная машина удобнее для редких ручных выпусков, но её легко оставить выключенной, занять другим проектом или потерять состояние Keychain. Собственный Mac требует закупки, обслуживания и постоянного хранения среды, а CI без доступного Mac не выполнит macOS-зависимую часть iOS-релиза. В такой ситуации аренда Mac в RUVCLOUD даёт более подходящую рабочую модель для повторяемых Archive, загрузки и восстановления после неудачной попытки, если команда заранее документирует подпись, артефакты и проверку App Store Connect.

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