Как тестировать подписки RevenueCat для iOS локально? Процесс на удалённом Mac в 2026 году

В процессе есть три разных тестовых маршрута — RevenueCat Test Store, StoreKit Configuration и Apple Sandbox; Apple описывает их как способы тестирования на разных этапах разработки. Быстрое решение: сначала проверьте логику приложения через Test Store, затем воспроизведите покупки с локальной конфигурацией StoreKit, а перед выпуском отдельно проверьте платформенную цепочку через Apple Sandbox. Успех в одной среде не означает, что две другие тоже прошли проверку.

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

Выберите среду по тому, что именно нужно доказать

Путаница обычно начинается с общего слова «тест»: разработчик видит успешную покупку и делает вывод, что подписка готова к публикации. Но тестовые среды отвечают на разные вопросы. Сначала определите критерий приёмки, потом выбирайте инструмент.

Оценки здесь — не замеры скорости и не гарантия совместимости. Это ориентир для выбора по цели. Возможности Test Store и его границы описаны в документации RevenueCat; назначение тестирования через Xcode и Sandbox изложено в документации Apple по тестированию на разных этапах.

Для практического порядка используйте такую шкалу приоритета:

• Проверка бизнес-логики и состояний экрана: сначала Test Store.
• Проверка локально задаваемого сценария покупки: StoreKit Configuration в отдельной Scheme.
• Проверка платформенного пути перед выпуском: Apple Sandbox с настроенными продуктами.
• Проверка условий, зависящих от реального устройства или целевой конфигурации: добавьте тест на соответствующем устройстве, если он нужен вашему сценарию.

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

До первой покупки сопоставьте товары, права и ключи

Перед запуском приложения проверьте, что сущности в RevenueCat связаны с теми же товарами, которые запрашивает приложение. В частности, сравните идентификаторы продуктов и убедитесь, что продукт связан с ожидаемым entitlement — правом доступа, которое приложение использует для разблокировки функции или подписки.

Порядок сверки:

1. Откройте проект RevenueCat и найдите продукт, соответствующий тестируемой подписке.
2. Сопоставьте его идентификатор с тем, который приложение передаёт при загрузке и покупке товара.
3. Проверьте связь продукта с нужным entitlement. Не полагайтесь только на название тарифа: приложение должно проверять ожидаемое право доступа, а не похожую строку в интерфейсе.
4. Проверьте конфигурацию SDK: для клиентского приложения используйте предназначенный для SDK публичный ключ, а не секретный ключ API.
5. Сверьте схему сборки и среду, для которой предназначены ключ, продукты и тестовый аккаунт.

RevenueCat описывает связь товаров iOS с правами в руководстве по настройке продуктов и entitlements, а принципы настройки SDK и ключа — в документации по конфигурации SDK. Это полезные контрольные точки, когда продукт в приложении отображается, но после покупки нужная функция остаётся заблокированной.

Проверяйте настройки как связку, а не по отдельности: идентификатор продукта → продукт в RevenueCat → entitlement → условие доступа в приложении. Если одно звено отличается, интерфейс может корректно показать экран покупки, но приложение не выдаст ожидаемое право. Для поиска причины запишите идентификатор пользователя RevenueCat, идентификатор продукта и результат чтения CustomerInfo — без токенов, паролей и приватных ключей.

Для примеров в заметках и задачах используйте только заглушки, например com.example.app.monthly и appl_public_example. Не копируйте действующие ключи в отчёт, снимок экрана или тикет. Публичный ключ SDK и секрет API имеют разное назначение; секретные значения не должны попадать в код клиентского приложения или в материалы, доступные всей команде.

Проверка перед запуском: убедитесь, что тестовая Scheme не использует ключ и набор продуктов, предназначенные для production. После переключения конфигурации повторно проверьте выбранные значения в текущем запуске Xcode, а не только файл настроек в репозитории.

Сначала проверьте покупку и права через Test Store

Test Store — подходящая первая остановка, если вы хотите узнать, корректно ли приложение реагирует на покупки, не превращая первую проверку в проверку Apple Sandbox. Он помогает проверить соединение приложения с RevenueCat и путь от результата покупки до состояния доступа. При этом тестовая покупка в Test Store не доказывает, что сделка прошла платформенную цепочку Apple.

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

1. Убедитесь, что приложение запускается с ожидаемым публичным SDK-ключом.
2. Загрузите настроенный продукт и проверьте, что экран подписки показывает тот вариант, который вы намеревались тестировать.
3. Выполните успешную тестовую покупку. Зафиксируйте реакцию интерфейса и результат CustomerInfo.
4. Проверьте, что нужный entitlement активен и приложение открывает соответствующую функцию.
5. Повторите сценарий с отменой или ошибкой, которые доступны в выбранной среде. Убедитесь, что приложение не выдаёт право доступа при неуспешной покупке и даёт пользователю понятную возможность вернуться к экрану.
6. Закройте и снова откройте приложение, чтобы проверить, как оно восстанавливает состояние доступа.

Сверяйте не только анимацию или сообщение «Покупка успешна». Запишите ожидаемый и фактический результат для CustomerInfo, entitlement и интерфейса. Если сообщение об успехе появилось, а доступ не открылся, проверьте связь продукта с entitlement и логику обновления состояния. Если доступ открылся после неуспешной операции, проверьте обработку ошибки и ранее сохранённое состояние пользователя.

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

Затем воспроизведите сценарий с StoreKit Configuration

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

Действуйте в отдельной Scheme, чтобы случайно не смешать локальный эксперимент с обычной сборкой:

1. Создайте или выберите файл StoreKit Configuration, содержащий необходимые для теста продукты.
2. В настройках Scheme назначьте этот файл для запуска тестовой конфигурации. Перед стартом проверьте, что выбранная Scheme действительно активна.
3. Сверьте идентификаторы локальных продуктов с теми, которые приложение запрашивает через RevenueCat.
4. Проверьте актуальную инструкцию RevenueCat для вашего режима тестирования: требования зависят от используемого SDK и выбранного способа запуска StoreKit Testing.
5. Запустите приложение и пройдите тот же сценарий: загрузка товара, покупка, обновление CustomerInfo и выдача entitlement.
6. После теста зафиксируйте, что сценарий выполнялся с локальным StoreKit Configuration, а не в Apple Sandbox.

Не делайте вывод «товар готов к выпуску» только потому, что локальная покупка прошла. Локальный файл предназначен для StoreKit Testing в Xcode; он не становится автоматически товаром в App Store Connect. Apple отдельно описывает обзор тестирования покупок в Sandbox, а RevenueCat объясняет различия между платформенными и локальными сценариями в материале об Apple App Store и тестировании.

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

Ответы на вопросы о тестовых средах

Можно ли тестировать без продукта в App Store Connect?

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

Чем Test Store отличается от Apple Sandbox на практике?

Test Store помогает быстро проверить интеграцию SDK и реакцию приложения на изменение покупки или прав доступа. Apple Sandbox нужен для отдельной проверки платформенной цепочки. Отмечайте в отчёте, какая именно среда использовалась: иначе успешный результат одного теста легко принять за подтверждение поведения, которое фактически не проверялось.

Как связать локальный файл StoreKit с RevenueCat?

Сначала подключите файл StoreKit Configuration к тестовой Scheme, затем проверьте совпадение идентификаторов локальных продуктов с теми, которые приложение запрашивает. После этого следуйте документации RevenueCat по выбранному режиму StoreKit Testing. Не выдавайте локальному файлу статус реального продукта: он не настраивает товар в App Store Connect автоматически.

Достаточно ли удалённого симулятора для проверки покупки?

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

Перед выпуском проверьте Apple Sandbox отдельно

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

Приёмку разделите на две независимые части.

Сначала проверьте транзакционный путь:

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

Затем проверьте представление товара:

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

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

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

Повторите проверку на удалённом Mac без смешения конфигураций

Удалённый Mac может выполнять сборку Xcode и запускать симулятор, если выбранная конфигурация и тестовый сценарий это поддерживают. Сам по себе удалённый доступ не меняет границы StoreKit или Apple Sandbox: он помогает воспроизводить сборку в отдельной среде, но не превращает локальный тест в платформенную приёмку.

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

1. Подтяните тот же коммит, на котором проводилась проверка локально.
2. Убедитесь, что открыли предназначенную для теста Scheme и не выбрали конфигурацию выпуска.
3. Проверьте доступность нужных файлов конфигурации и отсутствие секретов в репозитории.
4. Соберите приложение и запустите поддерживаемый тестовый сценарий в выбранной среде.
5. Проверьте покупку, CustomerInfo и entitlement; отдельно отметьте, проводился ли тест в Test Store, с локальным StoreKit Configuration или в Apple Sandbox.
6. Сохраните результат вместе с идентификатором коммита, названием Scheme, идентификатором продукта и категорией теста. Секреты и данные доступа в отчёт не добавляйте.

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

Для небольших команд удобно хранить результат в формате: «сборка и коммит», «Scheme», «среда покупки», «продукт», «ожидаемый entitlement», «фактический результат», «непроверенные границы». Такая запись помогает повторить тест и не приписывает Sandbox-проверке результаты, полученные в Test Store.

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

Решите, нужен ли вам удалённый Mac для этого этапа

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

У подхода без Mac есть конкретные ограничения: Windows или Linux не предоставляют локальную среду Xcode; один только Test Store не проверяет платформенную покупку Apple; доступ к чужому Mac может требовать передачи сборок и настройки тестового контура; а смешение локальной и выпускной конфигурации затрудняет повторную проверку. В то же время аренда не нужна, если у вас уже есть подходящий Mac и вы не выигрываете от изоляции среды, а для постоянной тяжёлой нагрузки собственное оборудование может оказаться уместнее. Если вам нужна временная среда для сборки и тестов Xcode, изучите вариант аренды Mac у MacDate и выбирайте его по фактическим требованиям вашего цикла, а не вместо проверки Apple Sandbox.

Главное правило тестирования подписок RevenueCat для iOS — фиксировать не только результат покупки, но и среду, в которой вы его получили. Сначала проверьте логику через Test Store, затем воспроизведите нужный локальный сценарий StoreKit и завершите отдельной проверкой Apple Sandbox перед выпуском; только так вы будете знать, какие части цепочки действительно прошли приёмку.