import { useEffect, useState } from 'react';
import { Platform } from 'react-native';
import Purchases, { PurchasesOffering } from 'react-native-purchases';
const API_KEYS = {
apple: "appl_your_ios_key",
google: "goog_your_android_key"
};
export function useRevenueCat() {
const [offering, setOffering] = useState<PurchasesOffering | null>(null);
useEffect(() => {
const init = async () => {
if (__DEV__) {
await Purchases.setLogLevel(Purchases.LOG_LEVEL.DEBUG);
}
const apiKey = Platform.OS === 'ios' ? API_KEYS.apple : API_KEYS.google;
await Purchases.configure({ apiKey });
try {
const offerings = await Purchases.getOfferings();
if (offerings.current !== null) {
setOffering(offerings.current);
}
} catch (error) {
console.error("Eroare la încărcarea produselor RevenueCat:", error);
}
};
init();
}, []);
return { offering };
}IAP-urile în Expo au fost mult timp un coșmar, mai ales înainte de apariția EAS Build și a Development Builds. Am integrat recent RevenueCat într-o aplicație cu peste 15.000 de utilizatori activi și am trecut prin toate furcile caudine ale configurării, așa că vreau să vă scutesc de câteva nopți pierdute.
Setup-ul de care nu scrie în tutorialele rapide
Toată lumea îți spune să instalezi SDK-ul și să configurezi produsele în dashboard-ul RevenueCat. Sună simplu, dar munca grea se dă în consolele Google Play și Apple Developer, unde birocrația te poate bloca zile întregi.
La Google Play Console, cea mai mare capcană este configurarea unui Service Account în Google Cloud Developer Console. Trebuie să-i dai drepturi de acces specifice pentru tranzacții financiare și query-uri de API, apoi să legi manual acel cont în Google Play. Dacă o singură permisiune lipsește, API-ul RevenueCat îți va returna o eroare generică de tipul "Product not available", fără alte detalii.
Pe partea de Apple Store Connect, asigură-te că ai semnat toate acordurile din secțiunea "Agreements, Tax, and Banking". Dacă nu ai completat formularele fiscale (cum ar fi faimosul W-8BEN-E), produsele tale in-app vor rămâne în starea "Ready to Submit", dar nu vor fi niciodată vizibile în sandbox.
De ce RevenueCat și nu implementare nativă?
Am avut cazul unui proiect mai vechi unde am scris de la zero validarea de rețete (receipt validation) pe un server Node.js. A fost o decizie proastă. Să gestionezi manual webhook-urile pentru refund-uri, perioade de grație (grace periods), upgrade-uri de tier-uri, downgrade-uri și cross-grade-uri între Android și iOS înseamnă sute de ore de muncă.
RevenueCat rezolvă asta complet și este gratuit până la 10.000$ venit lunar procesat.
Trade-off-ul sincer: Devii complet dependent de infrastructura lor. Dacă serverele lor au latență sau pică (și s-a mai întâmplat ocazional în trecut), utilizatorii tăi s-ar putea să nu își poată restabili achizițiile instant. Totuși, la un cost de 1% după pragul de 10k, trade-off-ul merită din plin pentru 95% din startup-uri.
Integrarea în Expo cu EAS
Uită de Expo Go. Librăria react-native-purchases conține cod nativ și necesită generarea unui Development Build. În app.json, va trebui să configurezi corect plugin-ul.
După ce rulezi npx eas build --profile development, vei avea o aplicație de test în care poți apela SDK-ul. Recomand activarea logurilor de debug în development; te vor salva de la ore întregi de ghicit de ce nu se încarcă produsele.
Secrete de testare în Sandbox
Pe iOS, nu folosi niciodată contul tău personal de iCloud pe simulator pentru a testa achiziții. Creează un cont dedicat de "Sandbox Tester" în App Store Connect. Când testezi, asigură-te că te loghezi în acel cont doar din prompt-ul de plată din aplicație, nu din setările generale ale telefonului.
Pe Android, testarea necesită să adaugi adresa de email a testerului în secțiunea "License Testing" din Google Play Console. Un detaliu enervant: după ce adaugi un produs nou în Google Play, poate dura între 2 și 6 ore până când Google îl propagă în CDN-urile lor de sandbox.
Voi ce folosiți pentru monetizare în React Native? Ați mers pe RevenueCat sau v-ați scris propriul microserviciu de validare a plăților?