StoreKit и RevenueCat ломаются не на API, а на кривой интеграции

StoreKit и RevenueCat ломаются не на API, а на кривой интеграции

Если приложение «не видит» покупки, проблема часто в мелочах: не тот product ID, два источника правды для подписки, неверный sandbox-аккаунт. Ваш пользователь не должен догадываться, куда нажать — то же правило работает и для логики оплаты.

Проверьте базовые точки:
• один и тот же идентификатор продукта в App Store Connect, StoreKit и RevenueCat
• один менеджер покупок, без дублирующих вызовов purchase()
• корректная обработка restore: покупка уже есть, но UI должен это показать
• listener подписки должен жить дольше экрана оплаты, иначе статус потеряется

Частая ошибка — хранить статус подписки только на клиенте. Клиент помогает показать экран, но решение о доступе лучше привязывать к серверу или хотя бы к актуальному entitlement из RevenueCat. Иначе после переустановки, смены устройства или сбоя сети вы получите «вечные» баги в доступе.

Еще одна боль — несинхронные состояния. Пользователь оплатил, а экран все еще просит купить. Тут спасает простое правило: сначала обновляем статус, потом показываем успех. Проверяем гипотезу, а не гадаем на кофейной гуще.

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