import Purchases from 'react-native-purchases';
const setupRevenueCat = async () => {
if (Platform.OS === 'ios') {
await Purchases.configure({ apiKey: 'appl_api_key' });
} else {
await Purchases.configure({ apiKey: 'goog_api_key' });
}
const offerings = await Purchases.getOfferings();
if (offerings.current !== null) {
// Afișăm pachetele din oferta curentă configurată în dashboard
console.log(offerings.current.availablePackages);
}
};Am stat acum vreo cinci ani să leg Apple de Google manual pentru un proiect de fitness și mi-a venit să-mi arunc laptopul pe geam după prima săptămână de debug. Validarea server-side a chitanțelor e un coșmar logistic: trebuie să gestionezi reînoiri, perioade de grație, refund-uri și schimbări de card. RevenueCat rezolvă fix mizeria asta de infrastructură. Recent, la un proiect cu peste 4k useri activi, am reușit să implementez tot fluxul de plată în mai puțin de două zile folosind Expo EAS.
Primul lucru pe care trebuie să-l înțelegi e că nu mai poți folosi Expo Go. IAP necesită cod nativ, deci treci direct pe expo-dev-client. Dacă încerci să testezi în simulator, o să primești erori criptice. Am pierdut vreo 3 ore pe un proiect vechi doar pentru că uitasem să fac un build nou de development după ce am adăugat plugin-ul de RevenueCat în app.json.
Configurația de bază și Entitlements
În RevenueCat, logica e puțin diferită față de magazinele de aplicații. Ai Produse (care sunt mapate 1:1 cu App Store/Play Store), Offerings (seturi de produse pe care le arăți userului) și Entitlements (ce primește userul de fapt, gen acces "Premium"). Recomandarea mea e să lucrezi mereu cu Entitlements în cod. Nu verifica dacă userul a cumpărat "monthly_subscription_v1", ci verifică dacă are entitlement-ul "pro_access".
De ce? Pentru că poți schimba prețul sau produsul din spate în dashboard-ul RevenueCat fără să mai urci un build nou în store. E un life-saver când vrei să faci un A/B test rapid pe prețuri. La un proiect de meditații am economisit cam 30% din timpul de deploy doar pentru că nu a trebuit să aștept review-ul Apple pentru o schimbare banală de tier.
Setup-ul de Store: Google e mai dur
La Apple, treaba e relativ simplă: faci un Shared Secret, îl pui în RevenueCat și gata. La Google Play, în schimb, trebuie să te joci cu Google Cloud Console, să creezi un Service Account și să-i dai permisiuni de vizualizare pe proiect. E un proces migălos și dacă uiți să bifezi o singură permisiune de "Financial data", n-o să-ți meargă nimic.
Un pont: asigură-te că produsele tale în Google Play sunt în starea "Active". Dacă sunt "Inactive" sau "Draft", API-ul de la RevenueCat o să returneze o listă goală de offerings și o să te scarpini în cap crezând că e bug în codul tău de React Native.
Testing și Sandbox
Testing-ul e partea cea mai frustrantă. Pe iOS, trebuie să-ți faci un user de Sandbox în App Store Connect. Pe Android, trebuie să adaugi adresa de mail a testerului în Google Play Console la secțiunea "License Testing".
Marele trade-off la RevenueCat? Costul. E moca până la 2.5k USD venit brut lunar, dar după aia încep să ia un procent. Pentru un startup la început, e genial. Dacă ești deja un gigant care învârte sute de mii de euro, s-ar putea să preferi să-ți scrii propria soluție de backend ca să nu le plătești lor taxa. Totuși, timpul de mentenanță salvat merită aproape orice comision în primele faze ale produsului.
Ați pățit și voi să vă respingă Apple build-ul pentru că butonul de "Restore Purchases" era prea mic sau ascuns? Mie mi s-a întâmplat de două ori la rând până am învățat lecția.