StoreKit и RevenueCat: 6 технических узлов, которые ломают подписку

StoreKit и RevenueCat: 6 технических узлов, которые ломают подписку

Интеграция кажется простой: SDK подключили, продукты завели, paywall показали. На практике чаще всего ломается не покупка, а связка «статус подписки → доступ к функциям». Давайте разберем цифры.

• Сначала проверьте идентификаторы продуктов. Они должны совпадать в App Store, в конфиге RevenueCat и в коде. Одна лишняя буква — и пользователь видит товар, но покупка не проходит.

• Не смешивайте логику интерфейса и логику доступа. Ваш пользователь не должен догадываться, куда нажать. Экран может быть красивым, но доступ должен открываться только после проверки entitlement, а не после успешного callback.

• Обрабатывайте три состояния: success, pending и failure. Если вы ждете только success, то потеряете пользователей с отложенной оплатой и поймаете странные баги в аналитике.

Важный момент — restore purchases. Его нужно ставить не как «спасательную кнопку», а как нормальный путь восстановления между устройствами. Иначе вы получите тикеты от людей, которые купили подписку, но вошли с другого аккаунта или переустановили приложение.

Еще одна ловушка — локальное хранение статуса. Кэш полезен для скорости, но источник правды должен оставаться на серверной стороне или в синхронизированном слое RevenueCat. Иначе отмена, возврат или смена периода будут расходиться с тем, что видит приложение.

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