The way to change your app's onboarding, paywalls, or surveys without shipping a build is server-driven UI: the screens are defined as data on a server, and an SDK inside your app renders that data as native components at runtime. Changing the flow means publishing new data, not new code, so nothing goes through review and every installed copy of the app updates within seconds. It is an established, guideline-compliant pattern used across top apps, and it is different in kind from over-the-air code injection.
Review is not the bottleneck. Your release train is.
Apple's own App Review page says 90% of submissions are reviewed in under 24 hours, and it is broadly true. The expensive part is everything wrapped around review: the code freeze, the QA pass, the phased rollout, and the long tail of users on old versions. A one-line copy change to your paywall inherits the full weight of that process, which in practice means growth changes ship monthly at best, and the installed base takes weeks to converge on them. Meanwhile the first session, where most of the win-or-lose happens, is exactly the surface you most need to iterate.
The spectrum of remote control
- Feature flags and remote config. Toggle prebuilt variations. Great for rollouts and kill switches, but every variant must already exist in the binary; you cannot flag your way to a screen you did not ship.
- Remote content. Strings, images, and prices loaded from a server into fixed layouts. Copy changes get cheap; structure stays frozen.
- Server-driven UI. Screen structure itself is data: which screens exist, in what order, with which components, branching, and targeting. New flows and reordered flows ship without a build. This is where onboarding and paywall iteration becomes a daily activity.
- OTA code push. Shipping new executable JavaScript to installed apps. Powerful, but it carries real guideline constraints (interpreted code must not change the app's core purpose or evade review) and real operational risk; it is a deployment strategy for engineers, not a growth surface for product teams.
Where the compliance lines are
Apple's guidelines restrict downloading executable code that changes what the app fundamentally is or does an end run around review. Server-driven UI sits comfortably inside the lines because what travels is configuration, not code: the components that render it shipped in your reviewed binary, and the app's purpose is unchanged whether onboarding has nine screens or twelve. This is the same architecture the largest apps on the store use for their own home feeds and offer screens. Two honest caveats: content you deliver remotely still has to follow the content and commerce rules (you cannot toggle in features that would themselves fail review, and purchases must stay inside the in-app purchase system where required), and if you later change the app's actual functionality, that is a binary update like always.
What belongs on the server
The surfaces worth moving out of the binary are the ones you should be changing weekly anyway:
- Onboarding flows: question order, screen count, value framing.
- Paywalls and upgrade prompts: placement, trial framing, pricing display.
- Surveys and feedback prompts: triggered by events, retired when answered.
- Feature announcements and permission primers: timed to moments, not releases.
Core product screens, navigation, and anything deeply interactive stay in code, where they belong. The split is not about moving your app to a server; it is about moving the growth surfaces that change twenty times a year.
What a week looks like once flows live on the server
The point of the architecture is a different operating rhythm, so here is the rhythm, concretely. Monday: the funnel shows a cliff on the goal-selection screen; you reword it and merge two questions, published by lunch, live on every installed version by lunch plus one minute. Wednesday: the cohort data shows the fix working, so you start an A/B test moving the paywall one screen later. Friday: a survey targeted at users who declined the paywall starts collecting objections for next week. Nothing shipped through review; engineering spent the week on the product.
Compare that to the same week on the release train: the Monday fix enters a branch, rides Thursday's release cut, reaches review Friday, rolls out phased next week, and hits most of the installed base the week after, at which point the Wednesday and Friday ideas are still in the backlog. Same team, same ideas, a quarter of the learning per month. Iteration speed is not a nice-to-have in growth work; it is the compounding variable, and release cadence is its ceiling.
The guardrails that make it safe
- Draft and publish separation. Edits happen on a draft; live apps only see published versions.
- Fallback behavior. If the network is unavailable, the app proceeds without the flow. Onboarding infrastructure must never be able to brick a session.
- Versioned rollout. New flow versions go live atomically; a bad publish rolls back the same way.
- An audit trail. When conversion moves, you want to know exactly which change moved it.
This is the architecture Setgreet provides out of the box: flows built in a visual editor or generated by AI, rendered as real native screens on iOS, Android, React Native, and Flutter, published to live apps in seconds, with drafts, targeting, and analytics built in. The FAQ covers the integration details; most teams are rendering their first server-driven flow the same afternoon.
Frequently asked questions
Is server-driven UI allowed by the App Store?
Yes. Configuration-driven native UI is standard practice; the guideline restrictions target downloaded executable code that changes the app's purpose or evades review. Your renderer ships in the reviewed binary; the server supplies data.
How fast do changes reach users?
Seconds to minutes, depending on the SDK's fetch strategy, and crucially they reach the whole installed base at once, including users who have not updated the app in months. No binary release can do that.
What happens if a user is offline?
A well-built SDK caches the last published flow and falls back to skipping the flow entirely if nothing is cached. The failure mode of good server-driven UI is "the user sees your app without the flow", never a broken screen.