Remote UI flows vs OTA code updates: what growth teams actually need

Search for "update onboarding without App Store review" and you will find guides about CodePush, EAS Update, and Capgo. They are useful. They are also answering a different question than most growth leads are asking.

Engineering wants to ship JavaScript bugfixes on Tuesday. Growth wants to change which screen comes before the paywall, test a shorter onboarding path, and branch on ATT denial without opening a PR. Both say "OTA." Both are over-the-air. The payload, owner, and policy boundaries are not the same.

This post separates OTA code updates from remote UI flows, explains what each is good for, and shows how mature teams run both without confusing the org.

Two types of OTA

Dimension	OTA code update	Remote UI flow
What ships	JS bundle, native binary patch (vendor-specific)	Flow manifest (screens, branches, copy)
Who ships	Engineering	Growth / product (with guardrails)
What changes	React components, logic, styles in app repo	Journey graph rendered by SDK
Typical tools	EAS Update, CodePush, Capgo	Rheo
Review risk	Policy limits on "significant change"	Flow content within SDK-reviewed binary
Experiment unit	Feature flags in code	Flow variants on canvas

Confusing the two leads to bad outcomes: growth files tickets to "use EAS Update for paywall test"; engineering pushes back on policy and ownership; nothing ships.

Code OTA: use cases

JavaScript OTA exists so mobile teams can fix production bugs and ship minor UI adjustments without waiting for store review.

Good fits:

• Crash fixes and null checks
• API endpoint changes
• Minor style tweaks in existing components
• Feature flags already merged in binary, toggled remotely

Poor fits for growth-led iteration:

• Reordering onboarding navigation (touches nav structure)
• Multi-branch experiments owned by non-engineers
• Cancel/win-back flows product wants to edit daily
• Localization churn on marketing copy across ten screens

React Native / Expo: EAS Update ships bundles to compatible runtimes. Your app must already contain the components. You are updating code paths, not handing growth a canvas.

Policy: Apple and Google restrict OTA changes that materially alter app purpose or circumvent review. Teams stay safe when OTA scope is engineering-owned, logged, and bounded. Massive UI rewrites via JS OTA invite review risk.

Code OTA is a deployment pipeline for developers. It is not a funnel experimentation platform for growth.

UI flow OTA: use cases

Remote UI flow platforms ship definitions that a native SDK renders. The SDK binary goes through App Store review. Day-to-day flow changes publish to Rheo's API and appear on next resolve.

Good fits:

• Onboarding sequence and copy
• Paywall placement inside a multi-step journey
• ATT pre-prompt and branch on grant/deny
• Cancellation surveys and save offers
• Win-back and feedback flows
• A/B tests on flow structure and timing

Poor fits:

• Core app tabs and main navigation redesign
• New native modules not in SDK
• Backend business logic changes

What growth gets: visual editor, publish button, step analytics, experiments without git push.

What engineering keeps: SDK version, purchase wiring, channel entry points, security review of initial integration.

Native rendering (Rheo's model) means flow screens use platform UI patterns, not a WebView of HTML uploaded OTA. Conversion-sensitive journeys benefit from that distinction.

Policy and compliance (high level)

Always read current Apple App Store Review Guidelines and Google Play policies. Summary for planning conversations:

Change type	Typical path
New SDK version in app	Store release
JS bundle fix (EAS/CodePush)	OTA within policy
Flow copy/branch publish (Rheo)	Remote manifest, no store
New payment mechanism	Store + billing review
Collecting new data types	Privacy review, possibly release

Flow OTA does not bypass store rules for the SDK itself. It moves flow iteration from release cadence to publish cadence after SDK integration.

Legal and compliance teams often prefer flow OTA over ad-hoc JS OTA for marketing copy because publish history, approvals, and rollback live in one dashboard.

Team ownership: eng vs growth

Task	Owner
SDK integrate, upgrade	Engineering
RevenueCat purchase delegate	Engineering
Onboarding screen 3 headline test	Growth (Rheo)
Crash fix in checkout	Engineering (EAS)
Cancel survey reason list	Product (Rheo)
New tab bar layout	Engineering (release)

Clear ownership prevents "why can't I EAS Update the paywall" meetings. Growth owns the journey graph. Engineering owns the app binary and code OTA.

Guardrails that work:

• Rheo: role-based publish, optional approvals, staging channels
• EAS: CI-only publish, no manual CLI from growth laptops
• Shared experiment calendar so code flags and flow tests do not collide

Combined stack pattern

Mature React Native teams commonly run:

EAS Update          →  app code, bugs, minor eng-led UI
RevenueCat          →  entitlements, offerings, revenue truth
Rheo                →  onboarding, lifecycle flows, flow experiments
AppsFlyer / Adjust  →  attribution
Amplitude           →  cohort analytics

User journey example:

1. Install attributed by MMP
2. Rheo channel first_launch resolves onboarding variant B (OTA yesterday)
3. Flow branches on ATT granted
4. Paywall screen triggers RevenueCat purchase
5. Rheo logs step funnel; RevenueCat logs transaction; MMP logs conversion event
6. Engineering ships feature fix via EAS without touching onboarding variant

Layers do not compete if boundaries are clear.

When Rheo is the right layer

Choose remote UI flows when:

• Funnel changes are weekly, not quarterly
• Test subjects are multi-screen paths, not one component
• PMs need to publish without JavaScript knowledge
• You need step-level drop-off, not only paywall convert
• Cancel, win-back, and permission branching belong in the same tool as onboarding
• Native UI quality matters for monetization screens

Stick to code OTA only when:

• Funnel is static and experiments are rare
• Engineering is the only role shipping user-visible changes
• Journey complexity fits in a few feature flags

Use both when you have a real app and a real growth function. They are complements.

Decision matrix

Your situation	Recommended primary layer
RN app, weekly flow tests	Rheo for flows + EAS for code
Native Swift, rare onboarding changes	Store releases until pain hits
Expo, eng-only OTA today	Add Rheo when PMs queue copy tests
Paywall-only experiments	Paywall vendor or RC Experiments
Full lifecycle (cancel, win-back)	Flow platform required

Cost of building in-house

Internal build vs buy math usually ignores ongoing cost:

In-house remote flows	Rheo
Schema design meetings	Canvas editor shipped
Custom admin UI	Dashboard included
Renderer maintenance per screen type	SDK renderer updates
Experiment stats	Built-in assignment + holdouts
On-call when JSON typo crashes onboarding	Publish validation

A senior engineer quarter building v1 DIY often exceeds annual Rheo cost for growth-stage teams. Build only if flows are truly static for 12+ months.

Real conversation starters for your next eng sync

Bring these questions to align teams in one meeting:

1. What flow changes did we ship last quarter, and how many required App Store review?
2. Where is the largest step drop-off, and who can publish a fix this week?
3. Do paywall experiments live in the same tool as onboarding, or do we reconcile spreadsheets?
4. When a user cancels, do we capture reason before they hit the store UI?
5. If growth wants a new ATT branch tomorrow, what is the eng estimate?

Honest answers reveal whether you need a journey layer or just better prioritization of existing tools.

Appendix: glossary for cross-functional teams

Term	Meaning
OTA code update	Shipping new JavaScript or bundle to existing app install
Remote UI flow	Server-published screen sequence rendered by SDK
Channel	Entry point that triggers a flow (e.g. first launch)
Trait	User attribute used for targeting (locale, plan, churn reason)
Holdout	Users excluded from treatment to measure incrementality
Flow-level metric	Success measured across full path, not one screen

Shared vocabulary reduces slack threads asking whether "OTA" means EAS or Rheo publish.

Closing the loop with leadership

When executives ask "why do we need another tool," answer with cycle time: days from hypothesis to published variant before vs after. Stack slides matter less than calendar speed.

Frame Rheo next to RevenueCat as CRM sits next to Stripe: different layer, same customer journey.

FAQ growth teams ask engineering

"Can we just use Remote Config?"
Config is key-value. You still build renderer, branches, editor, and analytics.

"Is this a WebView?"
Rheo renders native flow screens via SDK. Different from loading arbitrary HTML OTA.

"Does it replace EAS?"
No. EAS ships your app code. Rheo ships flow manifests.

"App Store rejection risk?"
SDK goes through review once. Flow publishes follow same model as other server-driven UI vendors; stay within disclosed behavior.

"Offline?"
SDK caches last resolved flow. Define fallback behavior for first launch offline in integration docs.

Summary

Growth teams searching "OTA onboarding" need remote UI flows, not another guide to bump expo-updates. Code OTA is essential engineering infrastructure. It does not give product managers a canvas, step funnels, or cancel/win-back lifecycle tools.

Know which OTA you are buying:

• Code OTA = ship JavaScript faster (engineering)
• Flow OTA = ship journeys faster (growth)

The best subscription apps run both, with clear boundaries and one entitlement source.

Start for free. Put iteration on the flow layer your growth team can own.