Mobile Engineering

RevenueCat in React Native: Sharing One Subscription Layer Across iOS and Android

6 min read | React · Subscriptions

The entitlement model is identical to any other RevenueCat integration — the same products, offerings, and entitlements we cover in our Flutter guide. What’s different in React Native is everything around it: RevenueCat’s SDK is a native module, and whether that’s a five-minute install or a half-day of tooling changes entirely on whether you’re in Expo’s managed workflow or a bare React Native project.

1. Managed Expo vs. Bare Workflow

Bare React Native
Native module installDirect
iOS pod install / Android syncStandard step
Works with Expo GoN/A
Managed Expo
Native module installNeeds a config plugin
Requires a dev buildYes
Works with Expo GoNo — native code required

The detail that catches teams out: a RevenueCat integration needs native code, which means Expo Go — the pre-built sandbox app most Expo projects start in — can’t run it. You need a development build (Expo’s own tooling for this, or EAS Build) before you can test a single purchase flow. Budget for this explicitly if your team has been living entirely inside Expo Go up to this point.

2. The Setup Sequence

1
Configure products and subscription groups store-side first
Same as any platform — App Store Connect and Play Console are the source of truth for what’s actually for sale, before RevenueCat or your app ever reference it.
2
Install the RevenueCat SDK and, if you’re on Expo, its config plugin
The config plugin handles the native project changes Expo’s managed workflow would otherwise hide from you — skipping it is the most common cause of “it works in bare React Native tutorials but not in my Expo app.”
3
Generate a development build before testing anything purchase-related
Expo Go will not show real purchase behavior — plan for a dev-build step in your test cycle from the start, not as a surprise later.
4
Define entitlements once, reference them identically on both platforms
Your JS code should check entitlement state the same way regardless of platform — if you find yourself branching purchase logic on Platform.OS, that’s usually a sign the entitlement model needs revisiting, not the code.
Gotcha

Fast Refresh does not reflect native SDK or entitlement changes. After adding or updating the RevenueCat native module, do a full rebuild rather than trusting a hot reload — this is one of the more common sources of “I fixed it but it’s still broken” during setup.

Once the SDK is wired up, the concepts — entitlements, products, offerings, sandbox testing — are the same regardless of framework; see our Flutter integration guide for the full breakdown of that model if you haven’t worked with RevenueCat before.


Wiring up subscriptions in a React Native or Expo app?

Tell us whether you’re managed or bare Expo and we’ll scope the setup around whichever workflow you’re actually in.

Start the Conversation →

Engineering Insights

Latest from Syntaxa Studio.

Loading latest posts