Entitlement w RevenueCat nie działa w React Native? Co naprawić przed premierą

Użytkownik zapłacił, RevenueCat pokazuje aktywność, a aplikacja React Native dalej traktuje go jak darmowego.

Skrót

Kiedy entitlement w RevenueCat nie działa w aplikacji React Native, problem zwykle nie leży w ekranie paywalla. Leży w połączeniu między konfiguracją produktu, identyfikatorami entitlements, tożsamością klienta, zacacheowanym customer info, restore purchases i bramką, która odblokowuje płatny dostęp. Sprawdź najpierw ID entitlementu w kodzie, potem potwierdź, że produkt jest do niego przypięty, że przed i po logowaniu używasz tego samego app user ID, że customer info jest odświeżane po zakupie, a płatna funkcja czyta stan entitlements z jednej centralnej warstwy dostępu. Jeśli te sprawdzenia są rozsypane po ekranach, zrób audyt zamiast łatać.

Najważniejsze fakty

• Udany zakup nie dowodzi, że aplikacja sprawdza właściwy entitlement.

• Product ID i entitlement ID to różne stringi i nie wolno ich mieszać.

• Aplikacje React Native często tracą płatny dostęp, gdy anonimowi użytkownicy RevenueCat logują się później.

• Testy w sandboxie i na TestFlight potrafią wyłapać błędy cache'u, restore i tożsamości jeszcze przed recenzją.

• Płatne funkcje powinny sprawdzać centralny stan subskrypcji, nie wynik kliknięcia w paywallu.

• Przebuduj warstwę płatności, gdy logika zakupu jest kopiowana po ekranach albo związana z niestabilnym logowaniem.

• Weź Ratunek dla aplikacji, gdy błąd przecina konfigurację, kod, logowanie i architekturę.

Zdiagnozuj awarię entitlementu, zanim ruszysz UI

Groźna wersja tego błędu jest cicha: zakup przechodzi, founder widzi klienta w RevenueCat, a aplikacja dalej otwiera paywall, chowa funkcję premium albo zapomina o dostępie po restarcie.

To bloker przychodu. Utrudnia też recenzję w App Store, bo subskrypcje muszą zachowywać się przewidywalnie.

Zacznij od dokładnego objawu:

• Paywall zawsze pokazuje się po zakupie.

• Restore purchases mówi, że się udało, ale funkcja zostaje zablokowana.

• iOS działa, Android nie, albo odwrotnie.

• Sandbox działa lokalnie, TestFlight nie.

• Anonimowi użytkownicy dostają dostęp, a tracą go po założeniu konta.

• Płatna funkcja odblokowuje się raz, a po restarcie znów jest zamknięta.

Każdy objaw wskazuje na inną warstwę. Nie proś agenta AI, żeby "naprawił RevenueCat", zanim nie ustalisz, która warstwa jest zepsuta. Taki prompt zwykle produkuje kolejnego lokalnego boola albo udawany stan sukcesu, który przykrywa prawdziwy problem.

Sprawdź ID entitlementów, nie ID produktów

Pierwsze sprawdzenie jest nudne i powszechne: kod może po prostu sprawdzać zły string.

RevenueCat ma produkty, offerings, packages i entitlements. Produkt to to, co sprzedaje sklep. Entitlement to poziom dostępu, który obchodzi Twoją aplikację.

Jeśli kod sprawdza customerInfo.entitlements.active["monthly_pro"], a entitlement nazywa się premium, użytkownik może zapłacić i nigdy nie odblokować funkcji.

Trzymaj jedną stałą z identyfikatorem entitlementu. Umieść ją przy serwisie subskrypcji:

const PREMIUM_ENTITLEMENT_ID = "premium";

Potem niech aplikacja zadaje jedno pytanie: czy bieżący klient ma ten entitlement aktywny?

Potwierdź, że produkt jest przypięty do entitlementu

Jeśli kod sprawdza właściwy entitlement, a RevenueCat nigdy go nie przyznaje, obejrzyj konfigurację w dashboardzie. Produkt musi być połączony z entitlementem przez poprawną konfigurację offering i package.

W aplikacjach generowanych przez AI prototyp często zatrzymuje się właśnie tutaj. UI pobiera offerings, pokazuje cenę i woła purchase. To wygląda na skończone, ale skończone jest dopiero wtedy, gdy aktywny entitlement odblokowuje prawdziwą funkcję.

Zweryfikuj app user ID przed logowaniem i po nim

Błędy tożsamości w RevenueCat łatwo przeoczyć w React Native, bo wiele aplikacji startuje z użytkownikiem anonimowym, a konto zakłada później.

Jeśli aplikacja konfiguruje RevenueCat anonimowo przy starcie, przeprowadza zakup, a potem loguje użytkownika do Supabase, Firebase albo własnego backendu bez poprawnej identyfikacji klienta w RevenueCat, subskrypcja może przypiąć się do innego klienta niż ten, którego aplikacja sprawdza po zalogowaniu.

Naprawa nie zawsze jest jednolinijkowa. Skonfiguruj RevenueCat na tyle wcześnie, żeby produkty się załadowały, zidentyfikuj użytkownika, kiedy logowanie ma już stabilne user ID, nie zmieniaj ID przy każdym starcie i trzymaj swój model użytkownika w zgodzie z klientem w RevenueCat.

Jeśli logowanie jest niestabilne, napraw je przed płatnościami. Przychód zależy od tego, czy wiesz, kim jest użytkownik.

Napraw ścieżkę dostępu, nie sam przycisk zakupu

Przycisk zakupu to jeden moment. Produkcyjny przepływ subskrypcji musi działać przy starcie aplikacji, rejestracji, wylogowaniu, restore, wygasłej subskrypcji, nieudanej płatności i offline.

Zrób centralną warstwę subskrypcji. Ma być właścicielem:

• configure i identify

• ładowania offerings

• wywołań zakupu

• restore purchases

• odświeżania customer info

• sprawdzania entitlements

• stanów ładowania i błędu

• zdarzeń analitycznych

Ekrany nie powinny wołać RevenueCat bezpośrednio, chyba że same są częścią tej warstwy. Ekrany funkcji mają zadać proste pytanie o dostęp i wyrenderować właściwy stan.

Na tym polega różnica między paywallem, który raz zadziałał w preview, a płatną aplikacją, która przeżyje użytkowników.

Odśwież customer info po zakupie i po restore

Po zakupie nie zakładaj, że UI ma się odblokować, bo promise się rozwiązał. Odczytaj customer info zwrócone przez RevenueCat albo pobierz świeże, a potem zaktualizuj centralny stan subskrypcji.

Ta sama zasada dotyczy restore purchases. Przycisk restore ma odświeżyć customer info, sprawdzić entitlement, zaktualizować stan aplikacji i wpuścić użytkownika do płatnej funkcji, jeśli dostęp istnieje.

Zbieraj zdarzenia: paywall wyświetlony, offerings załadowane, zakup rozpoczęty, zakup zakończony, zakup nieudany, customer info odświeżone, restore kliknięty, restore udany, płatna funkcja otwarta.

Bez tych zdarzeń nie odróżnisz problemu z konfiguracją sklepu, konfiguracją RevenueCat, tożsamością, cache'em i zepsutą bramką.

Zdecyduj: naprawa czy przebudowa

Napraw istniejącą implementację, gdy aplikacja ma jeden czytelny helper subskrypcji, stabilne logowanie, jeden identyfikator entitlementu i jeden lub dwa błędy konfiguracji.

Zrób audyt przed naprawą, gdy zakup działa na jednej platformie, a na drugiej nie, gdy anonimowi i zalogowani użytkownicy zachowują się inaczej albo gdy nie umiesz odtworzyć tego samego wyniku w sandboxie, na TestFlight i po czystej instalacji.

Przebuduj warstwę płatności, gdy kod RevenueCat jest skopiowany na kilka ekranów, płatny dostęp siedzi w lokalnym stanie, logowanie zmienia tożsamość użytkownika w nieprzewidywalny sposób albo nie ma jednego źródła prawdy dla użytkowników darmowych, w trialu, płacących, wygasłych i nieznanych.

Przebuduj całą aplikację tylko wtedy, gdy błąd płatności odsłania większy problem fundamentu: splątane logowanie, zduplikowaną nawigację, stan rozsypany po ekranach, brak właściciela backendu i brak drogi do gotowości na App Store. To jest moment, w którym paywall wygenerowany przez AI potrzebuje logiki RevenueCat, a nie samego UI, i w którym wąska naprawa staje się decyzją o premierze.

Porównanie

FAQ

Dlaczego RevenueCat pokazuje zakup, a aplikacja React Native dalej wyświetla paywall?

Aplikacja może sprawdzać zły entitlement ID, czytać nieaktualne customer info albo sprawdzać innego klienta RevenueCat niż ten, który kupił. Zacznij od zalogowania aktywnych entitlements z customer info po zakupie i po restarcie. Potem porównaj app user ID w RevenueCat z user ID, które Twój system logowania uważa za zalogowane.

To błąd RevenueCat czy mojego kodu?

Większość blokerów premiery to błędy konfiguracji, tożsamości albo stanu aplikacji, nie awarie RevenueCat. Traktuj to jak problem swojej integracji, dopóki nie udowodnisz, że produkt jest przypięty do entitlementu, SDK używa właściwego klucza API, app user ID jest stabilne, a świeżo pobrane customer info nadal nie ma oczekiwanego entitlementu.

Czy sprawdzać stan entitlementu w każdym ekranie premium?

Każdy ekran premium może pytać o dostęp, ale wszystkie mają pytać tę samą centralną warstwę subskrypcji. Nie kopiuj wywołań RevenueCat do każdego ekranu. Tak powstaje niespójne zachowanie ładowania, restore, cache'u i wygasłych subskrypcji.

Czy restore purchases jest konieczne?

Tak, w konsumenckiej aplikacji subskrypcyjnej na pewno. Użytkownicy przeinstalowują aplikacje, zmieniają urządzenia i testują przez sandbox albo TestFlight. Restore ma odświeżyć customer info i odblokować dostęp, gdy aktywny entitlement istnieje, a nie tylko pokazać ogólny komunikat o sukcesie.

Dlaczego entitlement działa przed logowaniem, a po rejestracji przestaje?

Zakup może być przypięty do anonimowego klienta RevenueCat, a zalogowana aplikacja sprawdza inne ID klienta. Napraw przepływ tożsamości tak, żeby RevenueCat używał stabilnego app user ID po logowaniu i nie tworzył nowego, niepowiązanego klienta przy każdym zalogowaniu.

Czy narzędzie AI to naprawi?

Pomoże poprawić znany błąd, ale potrzebuje precyzyjnego celu. "Napraw RevenueCat" jest za szerokie. Daj mu ID entitlementu, przepływ app user ID, logi customer info, zachowanie restore i ekran, który bramkuje płatny dostęp. Albo weź audyt od człowieka, zanim AI dołoży kolejny stan.

Kiedy umówić Ratunek dla aplikacji zamiast debugować dalej?

Umów Ratunek dla aplikacji, gdy problem przecina logowanie, RevenueCat, nawigację, analitykę i gotowość na App Store. Jeśli nie umiesz wskazać, gdzie zapada decyzja o płatnym dostępie, kolejne prompty dołożą łatek zamiast jasności.

Gdzie w cenniku Silpho znajdę pomoc przy wydaniu aplikacji?

Wejdź na cennik i wybierz poziom pomocy. Ship React Native Full to boilerplate DIY za 799 zł, Kickstart to boilerplate plus ścieżka 1 na 1 za 1 990 zł netto, Launch to done-for-you build gotowy na przychód, a Launch + Growth dokłada pełny system materiałów i ASO.

Następne kroki

• Porównaj cennik Silpho

• Przynieś kod do Ratunku dla aplikacji

• Przeczytaj przewodnik po logice paywalla w RevenueCat