Передача приложения в App Store Connect 2026: приём до и после

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

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

Магазинная передача и передача бизнеса — разные объекты

Самая дорогая ошибка — считать успешное принятие приложения завершением сделки. В App Store Connect может измениться владелец записи приложения, но это не означает автоматическую передачу всего, что поддерживает бизнес.

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

• запись приложения в App Store Connect;
• исходный код и история репозитория;
• серверы, базы данных и фоновые задания;
• домены, DNS и почтовые ящики;
• подписки и система проверки транзакций;
• ключи push-уведомлений и внешние интеграции;
• рекламные кабинеты, аналитика и CRM;
• служба поддержки и юридические страницы;
• устройства, сертификаты и профили подписи;
• пользователи и роли в Apple Developer Program.

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

До начала процедуры стороны фиксируют три решения:

1. кто является владельцем аккаунта со стороны отправителя;
2. кто принимает приложение со стороны получателя;
3. при каком наборе доказательств прекращается старый доступ и считается завершённой передача.

Практически это означает создание реестра активов. У каждого пункта должны быть ответственный, крайний момент выгрузки, место хранения, требуемый уровень доступа и статус подтверждения.

Проверка права на передачу: официальный фильтр против предположений

Право на передачу проверяется до согласования даты сделки. Официальные условия Apple включают состояние аккаунтов и соглашений, статус приложения, связанные покупки и отдельные ограничения конфигурации. Для этой проверки следует использовать официальные критерии передачи приложения Apple, а не старые инструкции из форумов.

Операционная команда должна сохранить обезличенные подтверждения:

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

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

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

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

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

Что архивировать до сделки: магазин отдельно, инфраструктуру отдельно

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

Архив магазина включает:

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

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

Инфраструктурный архив ведётся отдельно. Для него нужны карта серверов, переменные окружения без секретных значений, схема доменов, список webhook-адресов, расписание резервного копирования, перечень внешних поставщиков и инструкция отката.

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

Подписки, вход и push: где чаще всего ломается непрерывность

Передача приложения не обновляет автоматически все серверные связи. На практике наиболее рискованны четыре сценария.

Автоматические подписки

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

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

Sign in with Apple

Для Sign in with Apple нельзя ограничиться сменой команды в App Store Connect. Apple публикует отдельную документацию по переносу приложения и пользователей Sign in with Apple.

До сделки фиксируются:

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

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

Push-уведомления и связанные сервисы

Проверяются APNs, Wallet, Apple Pay, iCloud, Keychain Sharing и другие возможности только в том случае, если приложение их использует. Для каждого сервиса нужен владелец, список ключей, место хранения и процедура перевыпуска.

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

Права команды: минимальный доступ вместо общей учётной записи

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

Минимальная схема выглядит так:

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

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

Однако удалённый компьютер не меняет полномочия Apple. Он не обходит ограничения аккаунта, не ускоряет принятие передачи и не гарантирует сохранность сервиса. Для временной координации можно изучить варианты аренды Mac в SFTPMAC, а требования к правам нужно согласовать с владельцами аккаунтов.

Если в проекте участвуют несколько Apple Developer Program, полезно заранее разнести пользователей, браузерные профили и каталоги материалов. О подходе к изоляции нескольких аккаунтов разработчика следует думать как о контроле доступа, а не как о способе обойти правила Apple.

Условия решения: принимать сразу или останавливать сделку

Решение принимается по условиям, а не по одному экрану «Передача завершена».

• Если официальные критерии выполнены, соглашения действуют, а блокирующих состояний нет — можно переходить к согласованной передаче.
• Если право на передачу не подтверждено, но причина устранима — сделку следует поставить на паузу и назначить владельца исправления.
• Если приложение использует подписки, Sign in with Apple или push, но технический план миграции отсутствует — принимать запись без плана нельзя.
• Если код, домен или сервер не входят в договор — в акте нужно явно отметить, что они не переданы.
• Если получатель не может собрать и выпустить новую версию — приёмка считается ограниченной, даже если карточка доступна.
• Если прежние сотрудники сохраняют доступ после подтверждения удаления приложения из старого аккаунта — закрытие сделки откладывается.
• Если обе стороны работают на общем компьютере и не могут доказать, кто видел секреты — выбирается отдельная изолированная среда или меняются ключи.

Такой список превращает спор о «готовности» в проверяемое решение. Для каждого исключения указываются риск, владелец, срок исправления и условие повторной проверки.

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

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

1. Видимость магазина — карточка, локализации, цены, регионы и отзывы.
2. Непрерывность пользователя — вход, восстановление подписки, push и поддержка.
3. Публикация — доступ к Bundle ID, сертификатам, профилям, сборкам и TestFlight.
4. Собственность активов — код, домены, серверы, отчёты и внешние сервисы.
5. Отзыв доступа — пользователи, устройства, репозитории, ключи и старые каналы.

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

Пример команды для локального журнала проверки:

mkdir -p handover-evidence/{store,build,services,access}
date -u +"%Y-%m-%dT%H:%M:%SZ" > handover-evidence/check-time.txt
shasum -a 256 handover-manifest.csv

Пример результата:

2026-09-03T10:20:00Z
SHA256 (handover-manifest.csv) = [обезличенный хеш]

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

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

FAQ: частные вопросы участников сделки

Справочные страницы Apple нужно открывать непосредственно перед операцией. Для общей картины полезен обзор передачи приложения в App Store Connect, где разделены этапы процедуры и связанные последствия.

Сохраняются ли отзывы, рейтинг и Bundle ID?

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

Что проверять у автоматических подписок?

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

Почему Sign in with Apple перестаёт впускать пользователей?

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

Какие права и сертификаты нужны после принятия?

Получатель проверяет пользователей и роли, доступ к соглашениям, Bundle ID, сертификаты, профили и возможность загрузить новую сборку. Набор зависит от задач конкретного сотрудника. Общая учётная запись недопустима: каждый участник работает под своим Apple Account, а временные права отзываются после подтверждения результата.

Можно ли провести сделку только через удалённый Mac?

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

Для текущего варианта — общий офисный Mac, пересылка скриншотов в чат или хаотичная работа через личные ноутбуки — характерны смешение сессий, слабая история доступа, риск случайно показать секрет и зависимость от часового пояса одного сотрудника. Отдельная удалённая машина SFTPMAC может быть разумнее для временной передачи: на ней проще разделить пользователей, собрать доказательства и провести постпереносную проверку, не выдавая ей полномочий, которых у команды нет.

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