Remote onboarding flows in React Native and Expo

Hardcoded onboarding is the default in React Native and Expo projects. A stack navigator, five screens in src/onboarding/, copy in JSON files, and a feature flag in Remote Config if you are ambitious. Every copy tweak, new branch, or A/B variant still flows through a PR, QA, and often an App Store review before you learn whether it worked.

Remote onboarding flows flip the model. Engineering integrates the Rheo SDK once. Product and growth own screens, order, branching, and experiments from a dashboard. Publish hits production in seconds. The SDK renders native UI, not a WebView carousel dropped on your navigation stack.

This guide is for React Native and Expo teams evaluating that architecture: what changes in your repo, how the publish loop works, and when remote flows beat DIY Remote Config.

The hardcoded onboarding pain

Most RN onboarding pain is not technical complexity. It is iteration speed.

Change	Typical hardcoded cost
Headline copy on screen 3	PR + review + release
Swap paywall before vs after signup	Navigation refactor
Branch on ATT grant vs deny	Conditional screens in code
A/B test two flow lengths	Feature flags + two code paths
Localize new strings	i18n files + release

Growth teams file tickets. Engineering prioritizes against bugs and features. Experiments queue for the next sprint. By the time variant B ships, variant A's learnings are stale.

Distribution keeps sending installs into a funnel you cannot tune at the speed of paid acquisition. That mismatch is why remote flow platforms exist as a separate layer from your app binary.

Remote flow architecture

At a high level:

App launch → SDK resolve(channel, user traits) → API returns flow manifest
→ Native renderer paints screens → User actions → Analytics events → Dashboard

Your app owns:

• SDK initialization and auth context (user id, plan, locale)
• Channel entry points (first launch, post-signup, etc.)
• 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)
• Experiments and targeting rules
• Publish pipeline and version history

The manifest is JSON. The renderer is native React Native components (and native Swift/UIKit on bare iOS paths where applicable). You are not shipping JavaScript bundles that replace your whole app, as EAS Update does. You are shipping flow definitions that the SDK interprets into UI.

That distinction matters for team ownership: growth can publish flow changes without merging JS that touches your core navigation.

Expo vs bare React Native

Rheo supports React Native on iOS and Android today. Expo teams typically use a development build (not Expo Go alone) once native modules are required.

Topic	Expo (dev build)	Bare RN
SDK install	expo install + config plugin path per docs	Standard autolinking
OTA for flows	Rheo publish (flow manifest)	Same
OTA for JS app code	EAS Update (separate concern)	CodePush / EAS / custom
Store review	Still required for binary/SDK version bumps	Same

Practical note: EAS Update and Rheo solve different problems. EAS ships new JavaScript for your React components. Rheo ships new onboarding flows rendered by the Rheo SDK. Many teams use both: engineering ships app features via EAS; growth ships flow experiments via Rheo.

Do not expect Expo Go to render production Rheo flows without the native SDK in your build. Plan for expo prebuild and EAS Build as you would for any native dependency.

Integration steps (high level)

Exact APIs live in the developer docs. The integration shape is stable:

1. Install the SDK

Add @getrheo/react-native (or current package name per docs) to your project. Run pod install on iOS. Rebuild the dev client.

2. Initialize with user context

Pass stable user identifiers and traits the canvas uses for targeting: locale, platform, install_date, subscription_status, experiment assignments from your backend if needed.

3. Register channels

Map app moments to Rheo channels:

// Illustrative pattern. See docs for current API.
rheo.present('onboarding_first_launch');

First launch after install might call onboarding_first_launch. Returning users skip via targeting rules in the dashboard, not hardcoded if statements in your repo.

4. Wire purchases

When a flow screen triggers paywall, delegate to RevenueCat. Rheo emits funnel events; RevenueCat records revenue. Both datasets connect in your analytics stack.

5. Publish from dashboard

Design on canvas, preview in simulator, publish. The next present() call fetches the latest manifest.

Engineering work is front-loaded. Ongoing funnel work is dashboard work.

The publish loop

Remote onboarding only pays off if publish is safe and fast.

1. Draft on canvas (screens, branches, styles)
2. Preview in editor simulator (tap through branches, edge cases)
3. Publish to environment (production or staging channel)
4. SDK resolve on next presentation (cached with sensible TTL)
5. Measure step funnels and experiment lift
6. Iterate variant B without a release

Rollback is republishing a prior version, not reverting a git tag and waiting for review.

For teams used to EAS Update, the mental model is similar latency with a different payload: flow manifest instead of JS bundle. For teams used to nothing OTA, this is the first time growth can ship same-day.

A/B channels and targeting

Hardcoded A/B tests often look like:

const variant = await getExperiment('onboarding_v2');
if (variant === 'B') navigation.navigate('OnboardingB');

Remote flows move variant assignment to Rheo experiments or your existing experimentation layer feeding traits.

Patterns that work:

• Single channel onboarding_first_launch; Rheo splits traffic across flow variants
• Trait-based routing: country = DE → GDPR consent branch first
• Holdout percentage for incrementality measurement

Anti-pattern: duplicating channels per variant (onboarding_a, onboarding_b) when the experiment engine can split one channel. More channels means more operational overhead.

Step-level analytics tell you where variant B wins, not just that it wins. Screen 4 drop-off might be the story, not headline copy on screen 1.

vs DIY Remote Config

Teams sometimes ask: "Can we build this with Firebase Remote Config and a JSON schema?"

You can build a subset. You will still own:

• Schema versioning and migration
• A renderer for every screen type you invent
• Branch logic and validation
• Experiment assignment and statistics
• A dashboard non-engineers can use safely
• Native accessibility, fonts, and platform chrome

Remote Config is a transport layer. Rheo is transport + renderer + editor + analytics + experiment tooling purpose-built for multi-step journeys.

DIY makes sense at zero budget and zero funnel churn. Once onboarding and paywall experiments are a weekly habit, the build cost exceeds subscribing to a flow platform.

Capability	Remote Config DIY	Rheo
Change copy OTA	Yes (if you built UI binding)	Yes
Visual editor for PMs	No	Yes
Branching flows	Build yourself	Canvas
Step funnels	Build yourself	Built-in
Native rendering	Your components	SDK renderer
Time to first experiment	Weeks-months	Days

Performance and caching

Growth teams worry remote flows add latency at first launch. In practice:

• Manifests are small JSON payloads, smaller than most hero images
• SDK caches the last resolved flow for offline or slow network presentation
• Native render avoids WebView bridge cost on each screen transition

Profile cold start with and without Rheo in your staging build before assuming regression. Most teams see network fetch dominated by their own API calls, not flow resolve.

Versioning: each publish bumps a flow version in the dashboard. SDKs respect cache headers and explicit refresh on channel present. Force-refresh patterns belong in integration docs for QA.

Security and PII

Pass only traits needed for targeting: plan tier, locale, install cohort. Do not embed emails or names in manifest payloads. Rheo resolve is authenticated; treat API keys like any production secret.

Staging channels let QA preview unpublished flows without touching production users. Use separate API keys per environment.

When to migrate

Signals you are ready:

• Onboarding changes wait on app releases every week
• Paywall timing tests are backlog items, not live experiments
• RN onboarding tutorials solved "how to animate screens" but not "how to test them"
• RevenueCat is live but journey experimentation is not

Migration path: integrate SDK, recreate current onboarding on canvas, shadow traffic or run phased rollout, deprecate hardcoded screens once parity is verified.

Keep one emergency fallback screen in code if your compliance team requires offline-first launch. Most teams do not need it; SDK caching covers brief network gaps.

Testing remote flows in CI

Add a smoke test that calls resolve in staging with a test API key and asserts manifest schema version. Catch breaking SDK upgrades before production publish.

Snapshot tests on your own navigation are still valuable for core app tabs. Rheo flows preview in dashboard simulator for flow QA.

Summary

React Native and Expo teams do not need more carousel tutorials. They need a way to ship onboarding and paywall experiments at the speed of growth.

Remote onboarding flows:

• Integrate once via Rheo SDK
• Design and branch on a visual canvas
• Publish native UI over the air
• Measure per-screen, run A/B tests without app updates
• Complement EAS Update and RevenueCat, not replace them

Start for free. Wire the SDK once, then own onboarding from the dashboard.