Как отправить встроенную покупку в App Store Connect? Новый процесс Add for Review в 2026

На 29 августа 2026 года Apple подтверждает отправку встроенных покупок и подписок через Add for Review в соответствующем разделе App Store Connect. Практический вывод: первый товар каждого типа нужно отправлять вместе с новой версией приложения, а последующий товар обычно можно отправить отдельно, если такой тип уже имеет одобренный товар и у приложения есть одобренная версия. Это правило подтверждено в официальной инструкции Apple по отправке встроенной покупки.

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

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

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

Здесь не разбирается программирование StoreKit. Основная задача — правильно собрать объекты App Store Connect, не перепутать тестовую покупку с готовностью к App Review и понять, когда новая сборка действительно необходима.

Сначала определите, нужна ли новая версия приложения

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

1. какой тип товара отправляется;
2. есть ли у этого типа уже одобренный товар;
3. существует ли у приложения одобренная версия.

Именно сочетание этих условий определяет способ отправки. Одобренный consumable не означает, что первый non-consumable можно отправить отдельно. Аналогично, уже проверенная auto-renewable subscription не отменяет особый порядок для первой non-renewing subscription.

Таблица показывает важную границу: «первый» определяется не первым товаром вообще, а первым товаром конкретного типа. Это правило относится к составу App Review, а не к тому, была ли покупка технически успешной в Sandbox.

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

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

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

Add for Review не исправляет неполную карточку. Команда может успешно выполнить тестовую покупку, но получить задержку или отказ, если в App Store Connect отсутствуют обязательные данные для проверки.

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

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

Сведения нужно сопоставлять с требованиями к информации о встроенной покупке. Названия App, Product ID, Bundle ID, Team ID, адреса электронной почты, скриншоты с аккаунтами и фрагменты журналов перед передачей третьим лицам необходимо обезличивать.

Отдельная проверка для подписок

Для auto-renewable subscription недостаточно создать один товар. Необходимо проверить его принадлежность к правильной Subscription Group, соответствие уровням подписки и наличие описания, по которому рецензент поймёт различия между вариантами.

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

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

• техническая готовность — приложение получает ответ StoreKit, корректно выдаёт entitlement и обрабатывает восстановление;
• готовность к App Review — карточка товара, локализация, цена, территория, скриншот и Review Notes заполнены.

Эти состояния не заменяют друг друга.

Важно: успешная покупка в Sandbox или TestFlight доказывает только прохождение тестового сценария. Она не подтверждает, что товар можно отправлять отдельно и что его метаданные соответствуют требованиям App Review.

Первый шаг: соберите правильный черновик через Add for Review

В 2026 году отправка встроенных покупок в App Store Connect строится вокруг черновика проверки. Команда Add for Review находится в области управления In-App Purchase или Subscriptions. В зависимости от текущего состояния можно добавить товар в существующее незавершённое представление или создать новое.

Рабочая последовательность выглядит так:

1. Откройте нужное приложение в App Store Connect и перейдите к разделу встроенных покупок либо подписок.
2. Выберите товар, который должен пройти проверку, и убедитесь, что это правильный Product ID, а не похожий черновик.
3. Запустите Add for Review.
4. Выберите существующий черновик, если он уже содержит нужную версию приложения, либо создайте новый.
5. Для первого товара типа добавьте новую версию приложения в тот же набор.
6. Для последующего товара проверьте, действительно ли он подходит для самостоятельной отправки.
7. Откройте состав черновика и убедитесь, что в нём находятся именно те объекты, которые должны проверяться вместе.

При ответе на вопрос «где находится Add for Review» важно не искать только кнопку на странице версии. Она относится к потоку отправки товара из раздела управления покупками или подписками. Если кнопка не отображается, проверяются статус товара, наличие незавершённого черновика, права учётной записи и условия первой отправки.

Подробная последовательность переходов и актуальные ограничения описаны в обзоре отправки материалов на App Review.

Второй шаг: если требуется новая версия, примите сборку

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

Минимальный порядок проверки:

1. Соберите архив с корректным Bundle ID и схемой распространения.
2. Подпишите архив профилем и сертификатом, предназначенными для соответствующего приложения.
3. Загрузите Build в App Store Connect.
4. Откройте статус обработки и дождитесь результата, а не ориентируйтесь только на завершение команды загрузки.
5. Прикрепите обработанный Build к нужной версии приложения.
6. Установите приложение на тестовое устройство и проверьте, что экран покупки действительно доступен.
7. Проверьте восстановление покупки, обработку отмены и состояние пользователя после перезапуска.
8. Только после этого добавьте товар в черновик через Add for Review.

Статусы загрузки Build в App Store Connect полезны для разделения трёх ситуаций: файл ещё обрабатывается, обработка завершилась ошибкой или сборка уже доступна для выбора. «Uploaded» в журнале локального инструмента не означает, что версия готова к отправке.

Что учитывать при использовании Xcode 26

Для официального релиза следует использовать поддерживаемую Apple цепочку с Xcode 26 и проверять совместимость SDK, подписи и профилей. Xcode 26 нужно отличать от Xcode 27 beta: по состоянию на 29 августа 2026 года Apple допускает сборки Xcode 27 beta 6 для внутренних и внешних тестов TestFlight, но это не является подтверждением поддержки официальной клиентской дистрибуции в App Store. Актуальность этой границы нужно сверять с официальными сведениями о выпусках App Store Connect и страницами поддержки Xcode перед каждой публикацией.

В удалённой среде добавляются дополнительные точки отказа:

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

Для небольшой команды разумно разделить права: разработчику оставить доступ к сборке и тестированию, а публикационные ключи хранить в отдельном защищённом контуре. Роли и границы доступа следует сверять с официальным обзором ролей App Store Connect.

Третий шаг: проведите финальную проверку состава отправки

Перед нажатием Submit for Review полезно пройти чек-лист, не полагаясь на цвет статуса в одном разделе:

• [ ] выбран правильный App и Bundle ID;
• [ ] Product ID соответствует товару, который тестировался в приложении;
• [ ] тип покупки подтверждён отдельно, без предположения, что другой тип уже закрывает условие;
• [ ] для первой покупки типа добавлена новая версия приложения;
• [ ] для первой подписки в черновик включены Subscription Group и нужный товар;
• [ ] обработанный Build выбран в версии приложения;
• [ ] интерфейс покупки доступен без внутренних флагов разработчика;
• [ ] локализация, цена и территории продаж заполнены;
• [ ] скриншот и Review Notes объясняют, как рецензенту открыть покупку;
• [ ] тестовые инструкции не раскрывают реальные пароли, токены и ключи;
• [ ] после разрыва удалённой сессии подтверждены состояние Build и сохранённый черновик;
• [ ] в составе отправки нет старого товара или неправильной версии приложения.

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

Четвёртый шаг: отслеживайте объекты после Submit for Review

После отправки нельзя судить о результате только по состоянию Build. У приложения, товара, Subscription Group и самой отправки могут быть разные состояния. Справочник состояний приложения и отправки помогает определить, какой объект ещё ожидает действия.

При задержке проверяются:

• находится ли версия приложения на проверке;
• отправлен ли товар или он остался в черновике;
• не ожидает ли Subscription Group дополнительной информации;
• нет ли сообщения App Review по конкретному объекту;
• не завершилась ли обработка Build ошибкой после первоначальной загрузки.

Если товар отклонён, сначала открывается сообщение рецензента и определяется его объект: метаданные, скриншот, описание, сценарий покупки или поведение приложения. Исправление выполняется именно в соответствующей карточке. После этого используется Update Review или повторная отправка, если такой вариант доступен для текущего состояния.

Новая сборка не требуется автоматически. Она нужна, когда замечание относится к бинарному файлу: например, покупка недоступна в приложении, entitlement не выдаётся, восстановление не работает или интерфейс обещает доступ, которого фактически нет. Если проблема только в описании или Review Notes, повторная загрузка неизменённого Build добавляет лишний этап и может запутать историю релиза.

Пятый шаг: превратите отправку в повторяемый процесс

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

• тип товара;
• Product ID;
• признак первой одобренной покупки этого типа;
• связанная версия приложения;
• Subscription Group, если применимо;
• расположение скриншота и Review Notes;
• используемый Build;
• причина отказа и способ исправления, если отказ был;
• владелец публикационного действия.

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

Для регулярных релизов полезно разделить три операции:

1. сборка и локальная проверка;
2. загрузка Build и контроль обработки;
3. отправка товара и версии на App Review.

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

Какой вариант среды выбрать для следующей отправки

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

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

Если текущий процесс выполняется на Windows или Linux, браузерная панель сама по себе не заменяет macOS-инструменты: для Xcode, подписи и проверки приложения нужен доступ к реальному Mac. В таком случае можно заранее изучить варианты заказа удалённого Mac для разработки, а затем провести одну тестовую отправку по описанному чек-листу, прежде чем переносить на эту среду весь релизный процесс.

Главное решение для App Store Connect внутренне простое: сначала определяется, является ли товар первым для своего типа, затем проверяется наличие одобренной версии, и только после этого выбирается состав черновика Add for Review. Такой порядок предотвращает ситуацию, когда тестовая покупка уже работает, но новая подписка не может пройти отдельную проверку.

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