OpenAI + RevenueCat + Firebase in a React Native boilerplate

The stack

• React Native 0.83.6 + Expo SDK 55.0.17
• OpenAI: REST client in AI Pro
• RevenueCat: pre-wired
• Firebase Auth: @react-native-firebase/auth
• Firestore: @react-native-firebase/firestore
• Already shipped: Firebase Analytics, Crashlytics, Remote Config, FCM

Setup in five steps

1. Clone AI Pro

git clone <ai-pro-tier-repo>
cd ai-mobile-launcher
pnpm install

2. Add Firebase Auth + Firestore

pnpm add @react-native-firebase/auth @react-native-firebase/firestore
# google-services.json (Android) and GoogleService-Info.plist (iOS)
# already wired for Analytics/Crashlytics; same config files cover Auth + Firestore

3. Swap the auth feature

// src/features/auth/services/auth.service.ts
// Replace supabase.auth.signIn calls with firebase.auth().signInWith...
// Keep the same hook signatures so the rest of the app does not change.

4. Swap the data layer

// src/store/api/<feature>.api.ts
// RTK Query endpoints currently call Supabase. Replace queryFn with Firestore reads.
// The slice shape stays the same; the UI does not change.

5. Env

# .env
OPENAI_API_KEY=sk-...
EXPO_PUBLIC_REVENUECAT_IOS_KEY=appl_...
EXPO_PUBLIC_REVENUECAT_ANDROID_KEY=goog_...
# Firebase config comes from google-services.json / GoogleService-Info.plist

Why this combo works

Firestore makes sense when your data is hierarchical and read-heavy: chat threads, user-generated content, social features. Real-time listeners are first-class, not a SQL extension. Offline support is built in (the SDK caches reads/writes and reconciles on reconnect), which removes one of the harder mobile patterns.

You give up SQL, joins, and pgvector. So RAG features need a separate vector layer (Vertex AI Vector Search, Pinecone, etc.). For chat / messaging apps where vector search is not the core feature, Firestore is faster to ship than Postgres.

RevenueCat decouples your subscription state from the backend, which is the right call regardless of whether you use Firebase or Supabase.

What it costs at scale

Firestore cost is highly sensitive to read patterns. A chat app with real-time listeners on a long thread can blow the budget on a single power user.

What this combo does NOT cover

• Out-of-the-box Firestore wiring: Supabase is the default in the boilerplate. You do the swap
• pgvector / SQL joins: Firestore is document, not relational
• Row-level security in SQL: Firestore security rules are JSON-like, less expressive
• Self-hosting: Firebase is Google Cloud only