Keys in app.json
After setup, the following keys are added to your app.json (under the extra field):
| Key | Example | Description |
|---|
revenueCatApiKeyIos | appl_... | Production iOS API key |
revenueCatApiKeyAndroid | goog_... | Production Android API key |
revenueCatTestApiKey | test_... | Test Store key for dev builds |
revenueCatEntitlementId | pro | The entitlement to check (always “pro”) |
__DEV__ is true) and production keys in release builds.
Generated files
The AI agent creates or modifies these files:
| File | Purpose |
|---|
SubscriptionContext.tsx | React context provider wrapping the RevenueCat SDK. Handles initialization, purchase state, and optionally syncs user ID if auth exists. |
/paywall screen | The paywall UI where users can subscribe. Shows pricing, features, and purchase buttons. |
_layout.tsx | Modified to wrap the app in SubscriptionProvider and add a SubscriptionRedirect for enforcing the paywall. |
| Onboarding integration | If onboarding exists, the paywall is wired into the flow after onboarding completes. |
Dependencies
The react-native-purchases package is installed automatically.
Do not add react-native-purchases to the plugins array in app.json. This causes build errors. The SDK is configured entirely through SubscriptionContext.tsx, not as an Expo plugin.
How API key switching works
The generated SubscriptionContext.tsx includes logic like:
const apiKey = __DEV__ && testApiKey ? testApiKey : platformApiKey;
- In development builds, the Test Store key is used so you can simulate purchases safely
- In production builds, the real iOS or Android key is used for actual App Store / Play Store purchases
- This switching is automatic — you don’t need to change anything between environments
Storage key scoping
To prevent conflicts between multiple apps that might share the same Expo slug, the subscription context uses your Newly project ID in its storage key. This ensures subscription state is isolated per-app.
