Expo OTA limits for paywalls and onboarding: what Apple and Google allow
Policy clarity for Expo teams on what OTA can change for onboarding and paywall presentation vs what needs a store build.
Expo teams hear "ship onboarding changes OTA" and assume EAS Update can change anything in the funnel without App Store review. That assumption breaks in two places: store policy (what Apple and Google allow over the air) and architecture (what your binary already contains vs what a remote service can define).
This post clarifies expo ota limits for paywalls and onboarding: what EAS Update can safely change, what requires a new binary, how paywall vendors fit in, and how remote UI flows differ from JavaScript bundle updates.
For the conceptual split between code OTA and flow OTA, start with /blog/remote-ui-flows-vs-ota-code-updates.
Two OTA mechanisms Expo teams confuse
| Mechanism | What ships | Typical owner | Onboarding impact |
|---|---|---|---|
| EAS Update | JavaScript bundle to compatible runtime | Engineering | Changes React components already in app |
| Remote flow manifest | Flow graph (screens, branches, copy) | Growth / product | SDK renders native flow screens |
| Paywall vendor OTA | Paywall template / config | Growth via Superwall, RC Paywalls, etc. | Changes paywall surface only |
All three are "over the air." They are not interchangeable.
What EAS Update actually updates
EAS Update delivers new JavaScript to apps built with a compatible runtimeVersion. The update can change:
- React component logic and styles already imported in your bundle graph
- Copy strings inside those components
- Navigation between screens implemented in JS
- Feature flag reads that branch among existing screens
EAS Update cannot:
- Add native modules not in the binary (for example first install of
react-native-purchases-ui) - Change Expo SDK version without a new build
- Violate store rules on material functionality changes
- Give non-engineers a safe canvas if every screen change still requires a PR
Practical onboarding implication: reordering onboarding in React Navigation via OTA is possible if the screens exist in code. Adding a seventh onboarding screen with new native dependencies is not an OTA-only change.
Apple App Store policy (high level)
Apple's guidelines restrict updates that circumvent review or materially change app purpose. Interpretations evolve; your counsel and App Review history matter. Engineering teams commonly treat these as safe OTA boundaries:
Generally accepted for JS OTA (when binary already supports behavior):
- Bug fixes
- Minor UI adjustments within existing features
- Remote configuration among pre-shipped UI paths
- A/B tests among components already in the binary
Higher review risk via JS OTA:
- Large new user-facing features not present in reviewed binary
- Changes that alter core app category or primary purpose
- Monetization behavior that effectively ships new products without store review (gray area; prefer store product setup for new SKUs)
Requires App Store release:
- New native dependencies (billing UI modules, new SDKs)
- Expo SDK upgrades
- New entitlements or permissions strings in Info.plist
- New in-app purchase products (products are store-configured; UI can OTA within policy)
Apple cares about what the user experiences and whether you bypass review. Paywall and onboarding changes that only adjust presentation among reviewed capabilities are commonly OTA'd by mature teams. New purchase SKUs still flow through App Store Connect.
Google Play policy (high level)
Google Play has similar expectations for dynamic delivery and remote changes. Teams typically:
- Use Play Billing for digital goods (unchanged by OTA debates)
- Avoid OTA that introduces unreviewed major functionality
- Document remote update scope for compliance reviews
Cross-platform apps usually target the stricter of the two policies for OTA scope.
Paywalls and OTA: three layers
Paywalls touch billing. Split what OTA can change:
| Layer | OTA-friendly? | Notes |
|---|---|---|
| Products and prices | No (store config) | App Store Connect / Play Console |
| Entitlements / receipts | Server-side | RevenueCat, not OTA |
| Paywall presentation | Often yes | Superwall, RC Paywalls, remote templates |
| When paywall appears in journey | Flow OTA | Rheo channel experiments |
| Paywall native module first install | Store build | react-native-purchases-ui in binary |
Rheo does not manage paywall UI. External integrations (RevenueCat, Superwall, etc.) own paywall presentation and billing. Rheo orchestrates when the paywall step runs in a journey and records step outcomes.
Integration reference: /blog/how-to-use-rheo-with-revenuecat.
Onboarding and OTA: what teams try to do
| Change | EAS Update alone | Remote flow (Rheo) | Paywall vendor |
|---|---|---|---|
| Edit headline on screen 3 | Yes, if screen in code | Yes, on canvas | N/A |
| Reorder 5 onboarding screens | Yes, if nav supports | Yes | N/A |
| Add new screen with new native widget | No | No, unless SDK supports kind | N/A |
| Branch on ATT denial | Yes, with coded logic | Yes, native branch | N/A |
| Change paywall template | Via paywall SDK OTA | Triggers RC/Superwall node | Yes |
| Move paywall from screen 2 to 6 | Coded nav change | Channel experiment | Trigger change |
Expo Go vs dev client vs production
| Environment | Onboarding OTA | Paywall testing |
|---|---|---|
| Expo Go | Limited native modules | RevenueCat UI often fails (no native module) |
| Dev client | EAS Update works | Configure react-native-purchases-ui |
| Production | EAS Update + flow OTA | Full billing stack |
Rule: never conclude paywall OTA policy from Expo Go behavior alone. Test in a dev client matching production native deps.
Rheo flows should wire fallback edges on paywall nodes when presentation fails in Go.
EAS Update workflow checklist for onboarding and paywall changes
Before pushing an onboarding OTA via EAS Update:
- Runtime version matches production binary
- All screens in the test exist in shipped JS
- No new native imports in the update
- Feature flag or experiment assignment documented
- Rollback channel ready (
eas update --branch rollback) - Analytics events unchanged or backward compatible
- Paywall still delegates to billing SDK in binary
Before publishing a Rheo flow change:
- SDK version in app supports flow manifest features used
- Paywall integration enabled in Rheo app settings
- Fallback path on paywall nodes
- Freeze concurrent paywall vendor experiments if readouts matter
What not to OTA (common mistakes)
New billing SDK via JS OTA. Native modules require a build.
Brand-new onboarding flow with unsupported layer kinds. Flow SDK must already render those screen types.
Circumventing review for major features. Policy risk, not just technical risk.
Changing offering IDs without RevenueCat dashboard alignment. Presentation OTA fails silently or shows wrong packages.
Simultaneous EAS Update nav rewrite and Rheo channel test. Confounded metrics.
Remote UI flows vs EAS Update for growth teams
Growth asks: "Can we test a shorter onboarding without a release?"
| Approach | Growth self-serve? | Needs eng PR? | Policy framing |
|---|---|---|---|
| EAS Update | No (typically) | Yes, for code | JS among shipped components |
| Rheo flow publish | Yes | Initial SDK integration only | Manifest within SDK binary |
| Superwall / RC Paywalls | Yes for paywall | Billing in binary | Paywall template OTA |
Mature Expo stacks often run EAS Update for eng fixes and Rheo for flow experiments, plus RevenueCat/Superwall for paywall templates.
See stack context: /blog/flow-platform-subscription-stack.
RevenueCat and Superwall OTA on Expo
RevenueCat Paywalls: template and offering presentation can update from RC dashboard when SDK in binary supports Paywalls UI. Rheo triggers presentation at a flow step; RC owns the surface.
Superwall: paywall templates update remotely per Superwall docs. Still requires Superwall SDK in dev client/production binary.
RevenueCat Experiments: assignment and templates run on RC; freeze conflicting Rheo channel changes during readouts (/blog/revenuecat-experiments-vs-flow-level-testing).
Compliance documentation tip
Maintain a one-page OTA scope doc for App Review questions:
- What EAS Update may change (bugfixes, copy, flag-driven UI among shipped screens)
- What Rheo may change (flow graph, step order, branches)
- What paywall vendors may change (templates, not store products)
- What always requires store release (native deps, new permissions, new SKUs)
Reviewers and enterprise customers ask. A clear doc beats ad hoc explanations.
Decision matrix for Expo teams
| Question | EAS Update | Rheo | Store build |
|---|---|---|---|
| Fix onboarding typo in RN screen | Yes | Yes | No |
| Test 3 vs 6 step onboarding | Possible in code | Preferred | No |
| Add RevenueCat Paywalls first time | No | No | Yes |
| Change paywall headline (RC Paywalls) | No | Triggers node | No |
| Upgrade Expo SDK 52 → 53 | No | No | Yes |
| ATT branch experiment | Coded | Preferred | No |
Firebase Remote Config on Expo
Remote Config OTA's parameters, not components. Same policy ceiling as EAS Update for what those parameters activate. Comparison with paywall tools: /blog/firebase-remote-config-vs-superwall-onboarding.
Summary
Expo OTA limits for paywalls and onboarding boil down to: EAS Update changes JavaScript you already shipped, paywall vendors OTA templates on SDKs in your binary, and flow platforms OTA journey graphs rendered by an integrated SDK. Store policy draws the line on material new functionality, not on the word OTA.
New native billing UI, new SDKs, and new store products need a build. Copy, sequencing among supported screens, paywall templates, and journey variants are the usual OTA wins when tooling matches the layer.
Start for free to publish onboarding experiments OTA while keeping RevenueCat or Superwall on paywall presentation.