Как тестировать промокоды StoreKit в Xcode 27.2 RC? Руководство 2026

Промокод отображается в системном интерфейсе, но приложение не открывает доступ к функции — значит, проверяйте не экран оплаты, а обработку транзакции и выдачу прав.

Быстрое решение: настройте StoreKit Configuration и проверьте два независимых пути: погашение внутри приложения и симуляцию погашения вне приложения через Transaction Manager. В обоих случаях подтвердите обновление транзакции, выдачу прав и завершение обработки. Локальный тест не заменяет проверку в App Store Sandbox или реальном магазине.

Это руководство для разработчиков iOS-приложений, которые добавляют погашение промокодов к подписке или покупке и проверяют приложение на связке Xcode 27.2 RC и StoreKit.
Оно поможет проверить собственный обработчик транзакций и отделить локальную проверку от приёмки перед публикацией.

Последнее обновление: 30 октября 2026 года. Дата выпуска Xcode 27.2 RC и сведения о возможности загрузки сборок сверены с записями Apple Developer и обновлениями App Store Connect.

Локальная проверка или проверка магазина: что именно вы подтверждаете

StoreKit Testing в Xcode позволяет задать промокод в конфигурации и проверить погашение в локальном сценарии. Отдельно Transaction Manager позволяет имитировать погашение вне приложения и посмотреть, как приложение обрабатывает поступившую транзакцию. Это два разных пути, а не два способа открыть один и тот же экран. Документация Apple описывает эти этапы тестирования отдельно.

Оценка по готовности к публикации: локальная конфигурация — сильный инструмент для отладки логики приложения; Transaction Manager — отдельная проверка внешнего события; для подтверждения работы магазина нужна самостоятельная проверка в Sandbox. Не считайте локальный результат подтверждением реальной цены, доступности предложения или успешной публикации.

Важно разделять три события: система показала интерфейс погашения; приложение получило и обработало транзакцию; пользователь действительно получил соответствующие права. Первое событие не доказывает два следующих. Для StoreKit 2 приложение должно учитывать обновления транзакций через Transaction.updates, а после завершения необходимой обработки — корректно завершать транзакцию. В документации Apple по Transaction.updates описан канал получения таких обновлений.

Подготовка: настройте товар и конфигурацию StoreKit

До запуска сценария проверьте, что в проекте есть StoreKit Configuration, а нужный товар и промокод доступны именно в выбранной конфигурации. Файл конфигурации нужен для локального тестирования; он не является копией реальных товарных данных магазина и не должен восприниматься как источник действительной цены. Apple отдельно описывает настройку StoreKit Testing в Xcode.

Первая проверка: выберите правильный источник данных

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

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

Вторая проверка: отделите тестовые значения от магазинных

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

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

Не фиксируйте статус «промокод работает» по одному скриншоту системного окна. Критерий должен включать полученную транзакцию, изменение модели доступа и завершённую обработку.

Погашение внутри приложения: проверьте путь от интерфейса до прав

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

Действуйте по этапам:

1. Проверьте схему запуска. Убедитесь, что схема использует StoreKit Configuration с товаром и предложением для нужного сценария. Если схема не подключена к конфигурации, результат запуска нельзя считать проверкой локальных StoreKit-данных.
2. Откройте штатную точку погашения. Используйте кнопку или раздел приложения, предназначенный для предложения. Так вы тестируете тот путь, которым воспользуется пользователь, а не только отдельный системный экран.
3. Выполните погашение. Выберите настроенный для теста вариант и подтвердите действие в системном интерфейсе. Не делайте вывод об успехе только по факту показа этого интерфейса.
4. Проверьте получение транзакции. Проследите, что приложение получает соответствующее событие и связывает его с нужным товаром. При реализации StoreKit 2 включите в проверку обработчик обновлений, а не полагайтесь только на результат первоначального запроса покупки.
5. Подтвердите выдачу прав. Сверьте фактическое состояние модели доступа: нужная функция или подписочная возможность должна стать доступной согласно вашей бизнес-логике. Если транзакция получена, но права не изменились, ошибка находится после получения события, а не в отображении окна.
6. Завершите обработку. После проверки и применения результата выполните предусмотренное приложением завершение транзакции. Зафиксируйте в логах идентификатор товара, факт обработки и переход состояния без записи чувствительных данных пользователя.

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

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

Погашение вне приложения: как проверить Transaction Manager

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

Как сымитировать внешнее событие

Запустите приложение с нужным StoreKit Configuration, затем откройте Transaction Manager и выберите товар, для которого настроено предложение. Используйте предусмотренную менеджером симуляцию погашения вне приложения. Названия элементов интерфейса могут зависеть от версии Xcode, поэтому ориентируйтесь на назначение действия и актуальные инструкции Apple, а не на совпадение подписи с иллюстрацией из старого руководства.

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

Ожидаемая последовательность выглядит так:

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

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

Повторный прогон: проверьте существующие транзакции и право на предложение

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

Перед повторным прогоном:

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

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

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

Приёмка перед публикацией: локальный результат, Sandbox и удалённый Mac

Закройте тест не фразой «окно открылось», а набором проверяемых результатов. Для обоих путей — внутреннего и внешнего — зафиксируйте используемую схему и конфигурацию, тип инициированного погашения, полученное обновление, выданное право и завершение транзакции. Запись должна позволять другому разработчику воспроизвести сценарий, не подменяя внешнее событие внутренним.

С Xcode 27.2 RC следует сверять именно статус этой предварительной версии: запись Apple Developer указывает дату выпуска RC — 19 октября 2026 года, а заметки App Store Connect сообщают о возможности загрузки сборок этой RC в App Store и TestFlight. Эти сведения не означают, что статус RC автоматически совпадает со статусом другой версии Xcode. Перед релизом перепроверьте актуальные записи Apple, а не переносите выводы о загрузке на иную сборку.

Если вы запускаете тест на удалённом Mac, сохраняйте те же артефакты, что и при локальном запуске: выбранную схему, подключённую конфигурацию, логи обновлений и результат проверки прав. Сам факт удалённого доступа к рабочему столу не подтверждает, что StoreKit-сценарий запущен; успешное локальное погашение не подтверждает прохождение App Store Sandbox. Для оценки аппаратной среды и удалённого рабочего процесса отдельно изучите различия между macOS на выделенном оборудовании и виртуализацией.

Критерий выпуска: внутренний сценарий проверен через приложение; внешний сценарий — через Transaction Manager; в обоих случаях есть подтверждение обновления, корректной выдачи прав и завершения обработки. После этого отдельно проведите проверку, требующую App Store Sandbox. Не заявляйте о готовности к производству только на основании тестовой конфигурации Xcode.

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