How to A/B test onboarding in React Native without App Store releases
Step-by-step guide for RN teams to run onboarding experiments OTA without waiting on App Store review.
React Native teams know the drill. You have a hypothesis about onboarding: one fewer screen, a different value prop order, or a branch when ATT is denied. Engineering estimates a sprint. QA needs a build. Apple review adds days. By the time variant B is live, your paid campaign already spent against variant A.
React Native onboarding experiments should not require a store release for every copy change. The pattern that works for mature subscription apps is simple: integrate a remote flow SDK once, run experiments on a dashboard, and let the native renderer ship UI over the air. Your binary still goes through review when the SDK version changes. Day-to-day flow tests do not.
This guide walks through the architecture, setup, experiment design, and metrics for RN and Expo teams who want onboarding A/B tests at growth speed. For deeper integration detail, see Remote onboarding flows in React Native and Expo.
Why hardcoded onboarding blocks experiments
Most RN onboarding lives in a stack navigator under src/onboarding/. Screens are React components. Copy lives in JSON or i18n files. Feature flags might toggle between two hardcoded paths.
| Experiment idea | Hardcoded cost |
|---|---|
| Swap screen 2 and 3 | Navigation refactor + release |
| Test 4-screen vs 7-screen flow | Two code paths + flags |
| Branch on permission denial | Conditional logic in code |
| Localize new headline | i18n PR + release |
| Change paywall timing in journey | Touch nav + billing wiring |
Growth files tickets. Engineering prioritizes bugs. Experiments queue. Distribution keeps sending installs into a funnel you cannot tune at acquisition speed.
Remote flow experimentation removes the release bottleneck for journey structure, copy, branches, and placement of billing integration points. Rheo renders native UI from a published manifest. Product publishes variants without git push.
Architecture: one integration, many experiments
At a high level:
App launch → Rheo SDK resolve(channel, traits) → flow manifest
→ Native renderer → user actions → step analytics → dashboard experimentsYour React Native app owns:
- SDK initialization and user context (id, locale, plan tier)
- Channel entry (first launch, post-signup, re-engagement)
- Purchase callbacks wired to RevenueCat or your billing layer
- Deep links into specific channels when needed
Rheo owns:
- Screen layout, copy, images, and order
- Branches (single choice, multiple choice, text input)
- Experiment assignment and targeting
- Publish pipeline and version history
Your billing integration owns:
- Paywall UI, offerings, and purchase sheets
- Price presentation and package layout
- Entitlement state after purchase
Rheo orchestrates when users reach a paywall step inside the journey. RevenueCat, Superwall, or your custom paywall component still renders the paywall surface. Rheo records step-level funnel impact up to and through that integration node.
This separation matters for RN teams: you are not replacing your navigation tree with a WebView. The SDK interprets manifest JSON into native React Native components.
Expo vs bare React Native
| Topic | Expo (dev build) | Bare RN |
|---|---|---|
| SDK install | expo install + config plugin | Autolinking |
| Flow experiments OTA | Rheo publish | Same |
| App JS OTA | EAS Update (separate) | CodePush / EAS / custom |
| Store review | Required for SDK binary bumps | Same |
Practical note: EAS Update ships JavaScript for your app components. Rheo ships flow definitions the SDK renders. Many teams use both: engineering ships features via EAS; growth ships onboarding experiments via Rheo.
Expo Go alone typically cannot render production Rheo flows without the native SDK in your build. Plan for expo prebuild and EAS Build as with any native dependency.
Step-by-step: your first onboarding A/B test
1. Stabilize baseline integration
Before experimenting, confirm:
| Check | Why |
|---|---|
| SDK resolves on cold start | No silent failures on first open |
| Billing callback fires on purchase | Revenue truth matches funnel |
| Step events appear in dashboard | Analytics wired before variants |
| Staging channel works | QA can preview unpublished flows |
2. Recreate current onboarding on canvas
Mirror your existing flow screen by screen. Run shadow traffic or a phased rollout until step completion rates match baseline. Deprecate hardcoded screens once parity is verified.
Keep one emergency fallback screen in code only if compliance requires offline-first launch. Most teams rely on SDK caching for brief network gaps.
3. Define one hypothesis per experiment
Good first tests for RN onboarding:
| Hypothesis | Variants | Primary metric |
|---|---|---|
| Shorter path converts better | 4 screens vs 7 screens | Trial start or activation |
| Value props before signup | Benefits first vs account first | Step 3 completion |
| Permission timing | ATT before vs after value | ATT grant rate |
| Paywall placement | End of onboarding vs after activation | Reach paywall step |
Test one structural change per experiment when traffic is limited. Bold differences beat button color tweaks on small samples.
4. Configure traffic and mutual exclusion
Standard split: 50/50 for two variants. Do not overlap experiments on the same channel unless you have a factorial design and enough installs.
| Weekly installs | Suggested approach |
|---|---|
| Under 1k | Two variants max, bold changes, 2-4 week runtime |
| 1k-10k | 50/50 or sequential rounds |
| 10k+ | Multi-variant with power analysis |
5. Publish and resist peeking
Publish from the dashboard. Users on next resolve see assigned variant. Avoid daily significance checks. Pre-register runtime (often 2-4 weeks for small teams) and primary metric.
6. Read step funnels, not only outcomes
RN onboarding drop-off is rarely "the paywall failed." It is screen 4 with 40% exit. Rheo step analytics show where each variant loses users before they reach billing.
| Metric layer | What it tells you |
|---|---|
| Step completion | Which screen leaks |
| Branch rates | Permission or choice paths |
| Time on step | Confusion vs engagement |
| Paywall step reach | Journey quality before billing UI |
| Purchase completed (via integration) | Revenue outcome |
Wiring RevenueCat or other billing in the flow
Rheo does not manage paywall UI or pricing. Insert a billing integration node where the journey should present purchase:
- User completes onboarding beats in Rheo native screens.
- Flow reaches RevenueCat (or Superwall, etc.) node.
- External SDK presents paywall UI.
- Outcomes normalize:
purchase_completed,restore_completed,dismissed,failed. - Flow edges route users to activation, retry, or soft exit.
Experiments can change when users hit that node and what they saw before it. Paywall template tests stay in RevenueCat Experiments or your paywall vendor.
Common mistakes
| Mistake | Fix |
|---|---|
| Changing onboarding and paywall UI in one uncontrolled test | Split journey test (Rheo) from paywall UI test (billing tool) |
| No baseline funnel data | Run control-only until step rates are stable |
| Peeking at results daily | Pre-register end date |
| Passing PII in traits | Use cohort ids, plan tier, locale only |
| Expecting Expo Go for production QA | Use dev build with native SDK |
EAS Update and Rheo together
Teams often ask whether EAS Update replaces Rheo or vice versa. Neither.
| Tool | Ships | Owner |
|---|---|---|
| EAS Update | App JavaScript bundle | Engineering |
| Rheo | Flow manifest (onboarding graph) | Growth / product |
Use EAS for bugfixes and core app features. Use Rheo for onboarding experiments, permission branches, and lifecycle flows. Both are "over the air" with different payloads and policies.
When you still need an App Store release
Remote experiments do not eliminate store review entirely:
- New Rheo SDK version with renderer changes
- New native module dependencies
- Major app architecture changes outside flow scope
Plan SDK upgrades on a quarterly cadence. Run flow experiments between those releases.
Summary
React Native onboarding experiments without App Store releases require separating binary cadence from funnel cadence:
- Integrate Rheo SDK once in your RN or Expo dev build
- Recreate onboarding on a visual canvas with native rendering
- Run A/B tests on structure, copy, branches, and paywall placement
- Keep paywall UI and billing in RevenueCat or your chosen integration
- Measure step-level funnels before blaming the paywall
Start for free. Wire the SDK once, then run your next onboarding experiment without waiting on review.