StoreKit и RevenueCat: 7 технических мест, где ломается подписка

StoreKit и RevenueCat: 7 технических мест, где ломается подписка

Интеграция выглядит простой только на схеме. На практике ломаются не «платежи», а связка из продуктов, окружений и логики состояния. Ваш пользователь не должен догадываться, куда нажать.

• Проверьте, что один и тот же продуктовый идентификатор живет в App Store, в коде и в кабинете RevenueCat.
• Не смешивайте sandbox и production в тестах: из-за этого легко поймать фантомные подписки.
• Сохраняйте один источник правды по статусу доступа — не стройте логику только на локальном флаге.
• Обрабатывайте restore purchases отдельно: часть пользователей переустанавливает приложение или меняет устройство.
• Подпишитесь на серверные уведомления и сравнивайте их с клиентским состоянием. Клиент может молчать, сервер — нет.

Еще одна частая ошибка — игнорировать задержки между покупкой и обновлением прав. Если экран открылся раньше, чем пришел актуальный статус, пользователь видит «оплачено», но доступ все еще закрыт. Здесь помогает явная загрузка и повторная проверка статуса после покупки.

И не забывайте про отмены, возвраты и истекшие триалы. RevenueCat полезен именно тем, что снимает часть этой рутины, но он не отменяет проверку вашей бизнес-логики. Давайте разберем цифры: сначала убедитесь, что события покупки, восстановления и отмены одинаково понимают и приложение, и бэкенд. Тогда монетизация не развалится на первом же edge case.