Feature flags vs remote UI for mobile apps: which speeds up experiments?

Engineering ships LaunchDarkly or PostHog feature flags. Growth asks to test onboarding: five screens, two branches, new copy every week. Flags toggle booleans. They do not compose multi-step native journeys. The mismatch produces either blocked experiments or fragile flag spaghetti in src/onboarding/.

Feature flags vs remote UI for mobile apps is not a winner-take-all debate. Flags excel at engineering rollouts and simple gates. Remote UI flow platforms excel at growth-owned flow iteration. This post explains both models, when each wins, and how subscription teams graduate from flags to flows without ripping out existing tooling.

Two models side by side

Dimension	Feature flags	Remote UI flows
Payload	Boolean or multivariate key	Flow manifest (screens, edges, copy)
Who changes it	Engineering (typically)	Growth / product with guardrails
What must exist in binary	All variant code paths	SDK renderer; content remote
Experiment unit	Flag on/off	Flow variant on channel
Best tools	LaunchDarkly, PostHog, Firebase	Rheo
OTA character	Toggle pre-shipped code	Publish new graph content
Multi-step onboarding	Poor fit at scale	Core fit

Both can be "remote." The difference is whether you remote-control code paths already merged or journey definitions interpreted by an SDK.

What feature flags do well

Feature flags solve engineering problems:

Use case	Example
Gradual rollout	New editor to 5% of users
Kill switch	Disable broken API client
Simple A/B	onboarding_v2 true/false
Per-tenant entitlements	Enterprise feature gate
Ops safety	Turn off payment provider

Requirements for flag-based experiments:

1. Both variants implemented in app code.
2. Flag wired to branch logic.
3. Events instrumented per variant.
4. Engineering merges and releases flag infrastructure before test starts.

For a single screen with two layouts already built, flags are fast and fine.

Where feature flags break down for growth

Growth request	Flag reality
Change screen 3 headline	Needs code or CMS wired to flag
Reorder 6 onboarding screens	Navigation refactor per variant
Branch on ATT deny	Multiple compound flags
Weekly copy tests	Engineering queue
Cancel flow with 4 steps	New flag tree + release

Flags scale poorly with structural funnel change. Each new screen multiplies code paths. Non-engineers cannot safely publish.

Policy note: toggling flags that show materially different purchase flows may still need compliance review. Flags do not bypass store rules for what is in the binary.

What remote UI flows do well

Remote UI flow platforms (Rheo) ship manifests that a native SDK renders:

resolve(channel) → manifest JSON → native screens → analytics per step

Use case	Remote flow
Onboarding order and copy	Canvas publish
ATT pre-prompt placement	Branch nodes
Stories-style beats	Native sequence
Paywall placement in journey	Integration node timing
Cancel / win-back	Lifecycle channels
A/B on flow structure	Experiment on channel

Engineering integrates once. Growth publishes variants without git push. Store review applies to SDK binary updates, not daily copy changes.

Remote UI is not a replacement for all flags

Keep flags for:

• Core app features outside journeys
• Backend-kill switches
• Gradual release of native modules
• Experiments on screens that are not part of a Rheo channel

Remote UI does not replace LaunchDarkly for "use_new_sync_engine": true.

Feature flags vs remote UI: decision matrix

Question	Prefer flags	Prefer remote UI
Single screen, two layouts already built?	Yes	Optional
Multi-step onboarding restructure?	No	Yes
Growth owns copy cadence weekly?	No	Yes
Engineering-only rollout?	Yes	Overkill
Permission branches?	Fragile	Yes
Paywall timing in funnel?	No	Yes
Paywall UI / pricing layout?	No	No (billing tool)

Paywall reminder: Rheo does not manage paywall UI. Remote UI controls journey steps and when users reach a billing integration node. RevenueCat or your paywall vendor owns purchase surface experiments.

Combined architecture (recommended)

Mature mobile teams run both:

Concern	Tool
Core feature rollout	LaunchDarkly / PostHog flags
Onboarding and lifecycle journeys	Rheo remote UI
Paywall template	RevenueCat Experiments
Product analytics	PostHog / Amplitude

Anti-pattern: encoding entire onboarding as twelve flags (onboarding_step_3_variant_b). Pattern: one Rheo channel experiment with step analytics; flags only at channel entry if needed (use_rheo_onboarding).

Migration: graduating from flags to flows

Stage 1: Flags only

• Two onboarding versions in code.
• onboarding_experiment flag splits traffic.
• Works for first A/B, painful for iteration.

Stage 2: Hybrid

• Rheo SDK integrated.
• Flag chooses Rheo channel vs legacy hardcoded path.
• Migrate users to Rheo as parity proven.

Stage 3: Flow-native

• All onboarding via Rheo channels.
• Flags for non-journey features only.
• Experiments live in Rheo dashboard.

Stage	Growth velocity	Engineering load
1	Low	High per test
2	Medium	Integration sprint once
3	High	SDK upgrades quarterly

PostHog and LaunchDarkly users specifically

PostHog feature flags: strong for product analytics plus simple gates. Pair with Rheo by forwarding Rheo step events into PostHog with experiment_id. Funnels stay in PostHog; journey publishes stay in Rheo.

LaunchDarkly: strong for enterprise rollout and multivariate flags at scale. Use for app features. Do not force onboarding structure through LD without engineering per variant.

Tool	Keep for	Add Rheo for
PostHog	Retention, funnels, flags on features	Multi-step OTA journeys
LaunchDarkly	Rollouts, kill switches	Onboarding canvas

Remote UI vs OTA code updates (third option)

Teams sometimes conflate remote UI with EAS Update or CodePush. Different again:

	Feature flags	OTA code (EAS)	Remote UI flows
Ships	Toggle	JS bundle	Manifest
Owner	Eng	Eng	Growth
Onboarding restructure	Code flags	Still code change	Canvas

See Remote UI flows vs OTA code updates for the full comparison.

Instrumentation alignment

Whichever model you use, experiments fail without consistent events:

Property	Flags	Remote UI
experiment_id	Flag key + variant	Rheo experiment id
variant_name	Flag value	Flow variant label
step_id	Manual per screen	Native per step
Billing outcomes	RC events	Integration node

Align naming in a tracking plan before running parallel systems.

Security and ownership boundaries

	Flags	Remote UI
Who can publish	Usually eng-only	Growth with RBAC
Audit trail	LD / PostHog logs	Rheo publish history
PII in payload	Avoid in flag rules	Avoid in traits
Rollback	Toggle off	Revert publish version

Growth-owned publish demands staging channels and approval workflow. Engineering sets guardrails once.

Summary

Feature flags vs remote UI for mobile apps: flags speed up engineering rollouts and simple gates when variants already live in code. Remote UI speeds up growth-led onboarding, permission branches, paywall placement, and lifecycle flows when structure and copy change often.

Use flags for features. Use remote UI for journeys. Keep paywall UI in your billing integration. Most subscription teams need both, not either/or.

Start for free and graduate your next onboarding experiment from flags to native remote flows.