Как собрать приложение после App Store Connect App Transfer? Чек-лист передачи 2026

После App Transfer старый Mac всё ещё может показать успешный Archive, но это не доказывает, что новая команда сможет подписать, загрузить и выпустить приложение.

Самое быстрое решение: не переиспользуйте старые ключи и профиль как готовую инфраструктуру; сначала подтвердите Bundle ID и capabilities, затем создайте новую цепочку подписи на удалённом Mac и завершите её реальным Archive и загрузкой в TestFlight. На этой неделе передающей стороне стоит подготовить полный пакет материалов, а принимающей — запустить короткий двухконтурный период до отключения старой среды.

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

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

App Transfer меняет владельца приложения в экосистеме App Store Connect, но не превращает исходный Mac, пользовательскую папку и хранилище ключей в готовую среду принимающей команды. Apple указывает, что Bundle ID сохраняется, а связанный App ID передаётся принимающей стороне. Это не означает автоматическую передачу исходного кода, закрытых ключей, серверных секретов и всех внешних интеграций. Подробная схема доступных объектов приведена в официальном обзоре App Transfer.

Особенно опасны четыре смешения:

1. App Store record — запись приложения, история версий и связанные сведения в App Store Connect.
2. App ID и Bundle ID — идентификаторы приложения и его связь с командой разработчика.
3. Сертификат, закрытый ключ и Provisioning Profile — разные элементы цепочки подписи.
4. Исходный код, архив и IPA — материалы сборки, которые сами по себе не дают новой команде права подписывать будущие версии.

Передающей стороне также нельзя считать Apple Pay Merchant ID частью стандартного переноса: Apple отдельно указывает, что Merchant ID не передаётся вместе с приложением. Для Sign in with Apple требуется отдельная миграция пользователей и серверной логики по технической записке Apple о переносе пользователей.

Важно. Не удаляйте старые сертификаты, API Key, Runner и Webhook в день передачи. Сначала новая команда должна получить проверяемый результат: Archive, экспорт IPA, загрузку, обработку сборки и установку через TestFlight.

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

Проверка права на передачу

До начала операции нужно сверить критерии App Transfer: состояние приложения, соглашения, версии, ожидающие проверки или изменения, а также ограничения, связанные с аккаунтом. Конкретные условия необходимо проверять по официальным критериям передачи приложения, а не по старому внутреннему чек-листу.

Отдельно зафиксируйте:

• текущий Bundle ID и Team ID;
• список включённых capabilities;
• минимальные версии iOS / macOS и настройки Mac Catalyst, если они используются;
• активные схемы Xcode и конфигурации Release;
• способ управления зависимостями;
• серверы, которые проверяют bundle identifier, Team ID или подпись токена;
• действующие APNs-сертификаты и способ их замены;
• используемые App Store Connect API Key и Webhook.

В общий пакет следует положить не секреты, а карту секретов: имя, назначение, владелец, срок действия, место безопасной замены и условие отзыва. Значения Key ID, Team ID, путей, доменов и журналов в документации должны быть заменены на <KEY_ID>, <TEAM_ID>, <BUNDLE_ID> и другие заполнители.

Передача воспроизводимых материалов

Минимальный комплект должен включать исходный код, lock-файлы зависимостей, .xcodeproj или .xcworkspace, схемы, скрипты, настройки экспортных параметров, инструкции по окружению и список известных ограничений. Если предыдущая команда использовала fastlane, CI или собственные shell-скрипты, передайте не только конфигурацию, но и описание того, откуда поступают сертификаты и переменные среды.

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

• commit или иной идентификатор исходного состояния;
• конфигурацию, из которой был создан архив;
• ожидаемый Bundle ID;
• список entitlements;
• способ загрузки;
• сведения о том, какой серверный endpoint проверялся после установки.

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

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

Проверка объектов и разрешений

В App Store Connect проверьте, что принимающая команда видит приложение, его предыдущие версии и исторические сборки в пределах доступных прав. Затем в Apple Developer Account найдите переданный App ID и сопоставьте его с Bundle ID проекта. Несовпадение даже в одном символе приведёт к ошибке подписи или к загрузке сборки не в тот объект.

Не переносите на обычное приложение предположения, полученные из другого проекта. Особой проверки требуют:

• APNs и серверная отправка;
• Associated Domains;
• Keychain Sharing;
• iCloud container;
• Sign in with Apple;
• Apple Pay;
• Game Center;
• Webhook;
• Mac Catalyst;
• покупки и внешние серверы лицензирования.

App ID может быть передан, а внешний Merchant ID, серверный ключ или пользовательская миграция — нет. Именно поэтому приёмка должна идти по capability, а не по одному признаку «приложение видно в App Store Connect».

Новая цепочка подписи

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

Рекомендуемый порядок такой:

1. Войти в Apple Developer Account под принимающей командой.
2. Проверить Bundle ID и включённые capabilities.
3. Создать подходящий Apple Distribution certificate и закрытый ключ в новом защищённом хранилище.
4. Создать профиль с нужным App ID и проверить его entitlements.
5. Подключить профиль к Release-конфигурации или к системе автоматической подписи.
6. Выполнить локальную или удалённую сборку без изменения production-настроек.
7. Сравнить подпись, Team ID и entitlements с ожидаемыми значениями.

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

APNs нужно рассматривать в двух плоскостях: идентификатор приложения и серверная аутентификация. По официальной инструкции Apple для APNs TLS certificate новая команда должна проверить, какой сертификат или ключ используется сервером, к какому Team ID он относится и какой topic отправляется в запросе.

Составьте отдельный тест:

• новая установка получает push;
• приложение принимает push после обновления;
• сервер использует ожидаемый production endpoint;
• токен устройства обновляется и сохраняется;
• старый ключ можно отключить без потери расследуемости;
• журналы не содержат секреты и реальные токены в открытом виде.

Для iCloud, Associated Domains, Keychain Sharing и Game Center проверяйте не только наличие capability в Xcode, но и фактическое поведение установленного IPA. Для Sign in with Apple нельзя ограничиваться успешным входом одного тестового пользователя: серверная миграция идентификаторов должна быть проверена по отдельной процедуре Apple.

Удалённый Mac должен стать повторяемым рабочим местом новой команды, а не копией старой пользовательской среды. Для этого зафиксируйте поддерживаемую версию Xcode, зависимости, расположение проекта, команду Archive, способ экспорта IPA и канал загрузки.

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

На хосте выполните следующие действия:

1. Создайте отдельную учётную запись для новой команды, не используя личный профиль прежнего владельца.
2. Установите зафиксированную версию Xcode и проверьте доступность SDK.
3. Получите проект из доверенного источника и восстановите зависимости по lock-файлам.
4. Настройте подпись через новый сертификат, профиль или безопасную систему инъекции секретов.
5. Запустите графический Archive в Xcode.
6. Повторите Archive через SSH или CI с теми же входными параметрами.
7. Экспортируйте IPA и проверьте подпись, entitlements, Bundle ID и Team ID.
8. Выполните загрузку через согласованный канал.
9. Дождитесь обработки сборки в App Store Connect и проверьте её статус согласно справочнику Apple по статусам сборок.
10. Установите сборку через TestFlight и проверьте ключевые онлайн-функции.

В командах и журналах используйте только заполнители: xcodebuild -scheme <SCHEME> -configuration <CONFIGURATION> archive, путь <ARCHIVE_PATH>, профиль <PROFILE_NAME>, файл <EXPORT_OPTIONS_PLIST>. Не публикуйте реальные ключи, Team ID, пути домашнего каталога и фрагменты JWT.

Три результата нельзя объединять в один статус «готово»:

• Xcode создал архив;
• App Store Connect принял файл и обработал сборку;
• установленное через TestFlight приложение работает в реальном сценарии.

На первом этапе используйте версию с минимально рискованным изменением или заранее согласованный тестовый выпуск. После загрузки проверьте Bundle ID, номер версии, build number, подпись и entitlements. Затем протестируйте вход, push, покупки, iCloud, deep links, фоновые задачи и другие функции, которые зависят от переданного аккаунта.

При проблеме фиксируйте не только текст ошибки, но и этап: Archive, экспорт, загрузка, обработка, установка или выполнение функции. Это предотвращает типичную ошибку, когда успешный Archive принимают за доказательство исправной публикации.

Можно ли оставить старый Mac для сборки?

Да, но только как временный контур. Старый Mac может помочь сравнить результаты или завершить уже начатый выпуск, если прежние активы ещё действительны и доступ контролируется. Он не подтверждает готовность нового владельца. До его отключения новая команда должна самостоятельно выполнить подпись, экспорт IPA, загрузку и TestFlight-проверку.

Что делать с Apple Distribution и Provisioning Profile?

Сначала определите, какие старые активы ещё действуют, но не стройте на них долгосрочный процесс. Новая команда должна создать собственные сертификаты и профили, сопоставить их с Bundle ID и capabilities, а затем проверить entitlements в экспортированном IPA. Передача файла профиля без соответствующего закрытого ключа не восстанавливает полноценную подпись.

Нужно ли заново настраивать APNs?

Серверную конфигурацию нужно проверить и, как правило, обновить под новый аккаунт. Старый push-сертификат может временно оставаться действительным в пределах срока, указанного Apple, однако это не отменяет выпуска новой аутентификации. Проверяйте topic, Team ID, endpoint и поведение новой установки отдельно от обновления существующего приложения.

Как выполнить первый Archive на удалённом Mac?

Сначала подтвердите доступ к App ID и Bundle ID, затем установите зависимости и настройте новую подпись. Выполните Archive в Xcode, повторите команду через SSH или CI, экспортируйте IPA и загрузите его. После обработки в App Store Connect установите сборку через TestFlight. Только после проверки ключевых функций можно считать удалённый Mac рабочим контуром.

Что сохранить до начала App Transfer?

Сохраните исходный код, lock-файлы, схемы, скрипты, архивы, dSYM, экспортные настройки, список capabilities, сведения о push, Webhook, API Key, iCloud и серверных интеграциях. Значения секретов передавайте не в открытом документе, а через согласованный защищённый канал с ограниченным сроком действия. Отдельно запишите процедуру отката и условия отзыва старого доступа.

Передающая сторона

• [ ] Проверены условия App Transfer и статус соглашений.
• [ ] Переданы исходный код, зависимости, схемы и инструкции.
• [ ] Составлена карта сертификатов, профилей, APNs, API Key и Webhook.
• [ ] Сохранены архивы, dSYM и сведения о последнем стабильном выпуске.
• [ ] Описаны внешние сервисы, Apple Pay, iCloud и Sign in with Apple.
• [ ] Подготовлен план отката без передачи лишних закрытых ключей.

Принимающая сторона

• [ ] Подтверждены доступ к приложению, Bundle ID и App ID.
• [ ] Проверены capabilities и специальные интеграции.
• [ ] Созданы новые сертификаты, профили и закрытые ключи.
• [ ] Настроены APNs и серверная аутентификация.
• [ ] Выполнены графический и автоматический Archive.
• [ ] IPA проверен по подписи, Team ID и entitlements.
• [ ] Сборка загружена, обработана и установлена через TestFlight.

Владелец удалённого Mac и ответственный за выпуск

• [ ] Xcode и зависимости зафиксированы.
• [ ] Личные профили прежней команды не используются как постоянная инфраструктура.
• [ ] SSH / CI-сценарий повторяет ожидаемый Archive.
• [ ] Секреты вводятся через контролируемый механизм.
• [ ] Логи и артефакты доступны для расследования, но не содержат секретов.
• [ ] Старые Runner, Webhook, API Key и разрешения отзываются только после успешной приёмки.

Старый Mac, оставленный без новой подписи и контроля секретов, создаёт сразу несколько слабых мест: доступ к прежнему аккаунту, непрозрачный Keychain и зависимость от сертификатов, которые нельзя считать долгосрочными. Самостоятельный Mac устраняет часть этих ограничений, но требует покупки, обслуживания и постоянной защиты физического оборудования. Для переходного периода, первой публикации или временного CI-контурa удалённая аренда JEXCLOUD обычно удобнее, если нужны отдельный Mac, полный доступ администратора и среда, которую можно подготовить под новую команду без передачи старых личных данных. Подходящий сценарий можно сверить через руководство по развёртыванию удалённого Mac, а затем выбрать среду только после проверки требований к постоянной сборке и сроку хранения проекта.