How to update onboarding and paywalls without an App Store release

Every mobile team knows the pattern. Marketing wants new paywall copy before the weekend. Product wants to test a shorter onboarding path. Growth wants to branch users differently after a failed purchase. Engineering says the change is in review.

The App Store is not the enemy. It protects users and keeps the ecosystem stable. But when your funnel optimization runs at the speed of review, you lose weeks of learning on the journey that actually drives revenue.

This guide explains what you can change without a release, what still requires one, and how teams use Rheo for onboarding while their paywall integration owns billing UI, with both connected so you get a full view of how experiments affect paywall impact.

Why onboarding and paywalls get stuck in review

After install, most subscription apps follow a similar arc: onboarding screens, optional permission prompts, a paywall or trial offer, then the core product. Small changes to that arc can move trial starts and paid conversion by meaningful percentages.

The bottleneck is not ideation. Teams have plenty of hypotheses. The bottleneck is deployment:

Change type	Typical path without OTA	Time cost
Paywall headline and subcopy (in your paywall tool)	New binary + App Store review, or paywall-tool publish	2-14 days
Onboarding screen order	New binary + review	2-14 days
A/B test on two paths into the same paywall	Two builds or feature flags in code	Days to weeks
Branch after dismiss vs purchase	Code change + review	Days to weeks
Fix a typo on screen 3	Same as a full release	Days to weeks

When every iteration waits on review, teams batch changes, debate in meetings instead of data, and ship fewer experiments. Revenue compounds from small lifts on onboarding completion and conversion through the paywall step. Those lifts only happen when you can test fast.

What actually requires an App Store release

Be precise about what Apple and Google require a new build for. Confusion here is why some teams avoid OTA tools entirely, and why others over-promise what remote config can do.

Usually requires a new app version:

• New native dependencies or SDK major upgrades
• Changes to entitlements, capabilities, or Info.plist keys you have not shipped before
• New native UI components or custom native modules
• App icon, store listing, and binary-only features
• First-time integration of billing, attribution, or flow SDKs

Usually does not require a new app version (once your OTA layer is integrated):

• Onboarding screen copy, images, and layout within supported layer types
• Screen order, branches, and decision logic in a flow graph
• When and how users reach a paywall step (the paywall UI itself comes from your external integration, such as RevenueCat)
• Experiment arms and traffic allocation on a channel
• Translations and locale-specific variants

Rheo renders flows as native UI on iOS and Android, not a WebView shell. That matters for performance and trust, and it means you are not sneaking unreviewed HTML into the store binary. The SDK was reviewed when you shipped it; published flow versions are served over the air to that SDK.

The OTA workflow: design, publish, measure

Once the Rheo SDK is in your app and pointed at a channel, your team owns flows from the dashboard.

1. Design on the canvas

Build onboarding as a graph: screens, decisions, permission steps, and external integration steps such as a RevenueCat paywall node. Reorder by dragging nodes. Branch on answers, traits, or SDK attributes (for example, whether a purchase completed).

Preview the full journey in the editor simulator before you publish. Tap through branches and edge cases in seconds instead of waiting for TestFlight.

2. Publish a version

Publishing creates an immutable flow version. Channels pin to a version, or an experiment splits traffic across variants. Unpublished drafts never touch live users.

You can label versions ("Shorter onboarding v2", "Earlier paywall placement test") so analytics stay comparable when you filter by pin.

3. Assign to a channel

Your app passes a channel id to the SDK (ch_live_… or ch_test_…). Rheo resolves which flow version or experiment arm to serve. Change the assignment or start a test without shipping a new binary.

Keep a test channel for internal QA on a direct pin while live runs experiments.

4. Read funnels and iterate

Flow analytics show starts, completion, step-level drop-off, and cohort splits by platform, locale, app version, or experiment variant. When you see a cliff between two screens, fix it in the builder, publish, and pin the new version the same day.

That loop is what "ship today, learn today" means in practice.

Onboarding without a release: concrete examples

Here are changes teams ship OTA with Rheo regularly:

Hypothesis	What you change in Rheo	What you measure
Shorter path to value	Remove or merge screens; move paywall step later in the flow	Completion rate, time to complete
Stronger value prop	Headline, bullets, hero image on screen 1-2	Drop-off on early steps
Permission timing	Move ATT or notifications before/after paywall	Opt-in rate + downstream conversion
Post-dismiss path	Fallback edge after RevenueCat dismissed	Return visits, second-chance conversion
Locale-specific copy	Translations on the same graph	Completion heatmap by locale

None of these require Xcode or Gradle for copy and structure. Engineering set up the SDK once; product and growth iterate on the graph.

Paywalls stay in your integration; Rheo shows the full experiment picture

Rheo does not manage, design, or optimize paywalls. Your app still calls Purchases.configure with your keys. RevenueCat (or another enabled integration) still owns offerings, products, paywall templates, and receipt logic.

What Rheo adds is the onboarding journey that leads to that integration step and continues after it:

• Which screens users see before the paywall presents
• Which offering or placement to pass through at that step
• What happens on purchase_completed, dismissed, restore_completed, or failed
• Funnel analytics that tie experiment variants to paywall outcomes, not just isolated paywall metrics

Add a RevenueCat paywall node from the canvas, wire outcome edges plus a required Fallback, and publish. The SDK presents RevenueCat's UI when the flow reaches that node and branches from normalized outcomes.

You can change onboarding screens, timing, and branches OTA in Rheo. Paywall copy, layout, products, and prices stay in your paywall integration. Together, Rheo plus that integration gives you a full view of how onboarding experiments affect paywall impact: step-level drop-off before the paywall, presentation rates, and downstream conversion by variant.

What to keep in your release train

Reserve App Store releases for work that truly needs native code:

• Initial Rheo, RevenueCat, and MMP SDK integration
• New OAuth providers or canvas capabilities disabled at the app level
• OS permission types you have not declared yet
• Performance fixes in native modules
• Store policy changes that affect binary metadata

Everything else in the post-install funnel should default to OTA so your release train serves the product, not every copy tweak.

Rollout hygiene: test, live, and experiments

Environment	Purpose
Test channel	Internal builds, QA, staging keys
Live channel	Production users
Experiment on live	Split traffic across published variants

Use stable userId in the SDK so experiment bucketing stays consistent across sessions. When an experiment ends, promote a winner to the channel pin so everyone gets the best variant.

Avoid changing traffic weights mid-flight without a documented reason. Extend the end date if sample size is thin rather than chasing noise.

Common objections (and answers)

"Apple will reject remote UI."
Apple's guidelines target binary changes that bypass review for executable code. Rheo serves declarative flow manifests to an SDK already in your reviewed binary, similar in spirit to remote config for native screens you authored in a controlled system. Your team still owns compliance; Rheo gives you a native renderer and audit trail via versioned publishes.

"We already use feature flags."
Flags are great for boolean gates. They are awkward for multi-step journeys with analytics per screen, branching on paywall outcomes, and visual editing for non-engineers. Rheo complements flags: use flags for kill switches; use flows for the journey itself.

"Our paywall is all in RevenueCat."
Keep it there. Rheo does not replace your paywall integration. It routes users to that step, branches on outcomes, and connects flow experiments to paywall impact so you can see which onboarding variants drive more presentations, purchases, or dismissals.

Measuring success after OTA publishes

Each publish should tie to a metric you can read within a week:

Goal	Metric in Rheo	Secondary check
More users finish onboarding	Completion rate	Median time to complete
More users reach the paywall step	Funnel throughput to integration node	surface_presented count
More trials or purchases	Outcomes after paywall step (iap_purchase, period type)	RevenueCat dashboard
Better permission opt-in	OS permission outcomes in timelines	MMP attributed installs

Compare equal-length date windows before and after a pin change. If traffic is spikey, run an experiment instead of a hard cutover so assignment stays clean.

Collaboration without engineering bottlenecks

OTA flows change who can ship:

• Design edits layout, imagery, and motion on the canvas.
• Growth edits copy, branches, and experiment weights.
• Engineering owns SDK integration, RevenueCat configure, and custom sdkAttributes from the host app.

Comments in the flow editor anchor to nodes for review threads. Publish approvals can follow workspace policy on sensitive channels. The handoff is "publish and pin," not "open a ticket and wait for the next release train."

Getting started

1. Integrate the Rheo SDK in your React Native app (Expo dev client or bare workflow).
2. Enable RevenueCat under App settings → Integrations if you use paywall integration nodes.
3. Create a flow, publish a version, assign it to a test channel, and verify on device.
4. Duplicate the flow for experiments, or pin improvements to live when ready.

The goal is not to avoid the App Store forever. It is to stop treating every funnel hypothesis like a release event. Ship flows at the speed of learning, and reserve App Store cycles for the native work that actually requires them.

Start for free