Server-driven app UI: architecture, compatibility and rollout
Compare remote configuration, templates and server-driven layouts. Plan client compatibility, renderer trials, failure handling and a verified rollout.
A team wants to change an onboarding question, reorder a paywall, or remove an expired promotion. Server-driven app UI can let an installed app receive those presentation changes without another binary release, provided its runtime already supports the requested behavior.
The architectural decision is how much control to move to the server and what the client must still own. This guide compares remote parameters, templates and composed layouts, then gives you a compatibility contract and a release worksheet for evaluating one surface.
What server-driven app UI means
In a server-driven UI system, a remote definition controls some combination of content, layout and interaction. The installed app interprets that definition through capabilities it already has. A server response might select a predefined screen, provide values for a template, or describe a tree of components.
Apollo's SDUI guide describes an API returning presentation-oriented information and recommends incremental adoption. GraphQL is one possible implementation; the design decision is the contract between the definition and the client.
The delivery model does not determine the renderer. A system can map definitions to platform views, use a shared custom renderer, or present web content. Evaluate accessibility, text input, navigation, purchase handoff and frame timing on your actual devices. None of those properties follows automatically from the label “server-driven.”
Remote configuration, hydrated templates, or server-driven layout?
Remote app UI describes a delivery choice: some presentation decisions arrive after the app is installed. A server-driven component tree is one way to make that happen. Another is to keep the screen structure in the app and fill approved slots with remote text, images, offer identifiers, or a choice of existing templates.
| Approach | What the installed client owns | What a remote change can select |
|---|---|---|
| Remote parameters | The screen and code paths that consume each parameter | Values such as a headline, theme choice, or an existing feature flag |
| Hydrated templates | A fixed set of layouts and the behavior of their slots | Content and supported template variants |
| Server-driven component tree | The renderer, supported components, action handlers and compatibility checks | A composition within the client's supported vocabulary |
Choose the smallest surface that supports the change you need. A team changing welcome copy may need parameters. A team rearranging a multistep onboarding experience may need a richer composition model. Neither approach can assume that an older client understands a component or action it has never shipped.
Firebase Remote Config illustrates the parameter approach: the app defines defaults, fetches overrides, and controls when values become active. Fetching a value and applying it are separate operations. This distinction matters when a customer is already halfway through a journey.
A release-incident worksheet for remote UI
Consider an illustrative subscription app whose optional onboarding question has become a dead end on an older app version. The immediate job is to restore a usable path while preserving the customer's progress. A full redesign can wait. This is an engineering example, not a Nuxie customer incident or measured result.
- Define the affected population. Record the app version, platform, entry point and last completed step. Confirm that the failure occurs in the delivered version rather than assuming every customer is affected.
- Choose a supported change. If the installed client already supports skipping the optional step, prepare that route. If the repair needs a new native action, schedule an app update instead of encoding an unsupported command in the payload.
- Specify activation timing. Decide whether the new definition applies at the next journey entry or whether existing sessions can migrate safely. Keep an explicit rule for a customer who returns after backgrounding or losing connectivity.
- Exercise the fallback. Test a first launch with no downloaded artifact, a cached prior version, a failed asset request and an unsupported definition. The customer should reach a known route with a clear retry or exit path.
- Retain the previous version. Record the reviewed artifact and how to restore it. Assign an owner to watch errors and the intended completion event after publication.
- Verify the delivered result. Confirm which version an eligible device receives and whether it can finish the journey. A successful publishing request alone does not establish either result.
Keep the repair's operational result separate from a growth claim. Restoring navigation can be checked with a reproducible test. Claiming better conversion requires an appropriate measurement design, comparable populations and enough evidence.
For Nuxie's version boundary, see the publishing guide: editing an Experience does not change the live version; the existing version remains active while an update builds. Use the product's documented publication behavior when adapting this worksheet, rather than assuming every remote-UI platform has the same rollout controls.
Write a client compatibility contract
Before adding a remote screen, write down the decisions each installed version can interpret. A useful contract makes an unsupported definition a predictable case rather than a surprise in production.
| Contract area | Decision to record | Verification example |
|---|---|---|
| Components and properties | Supported types, required properties, defaults and size limits | An older client receives an unknown component and reaches the intended fallback. |
| Actions | Allowed navigation, dismissal, event and purchase actions | A malformed action cannot invoke an arbitrary native operation. |
| Eligibility | App versions and capabilities required by the definition | A client below the minimum supported capability receives the existing route. |
| Session continuity | When a definition can change for someone already in a Journey | Backgrounding and returning does not erase an answer or duplicate a purchase. |
| Failure behavior | First-launch, offline, expired-content and missing-asset behavior | A fresh installation without cached content still offers a usable exit or fallback. |
Treat these as engineering acceptance cases, not features every remote UI vendor necessarily provides. Keep authentication, access enforcement and purchase verification with the systems responsible for them. Hiding a button is not an entitlement check.
Choose a renderer with a device trial
Start with the hardest interaction on the proposed surface. A static headline is a weak test if the production experience includes a keyboard, animation, screen-reader navigation and a purchase sheet.
- Platform-view mapping: inspect how each platform implements the shared component vocabulary, including differences in layout and interaction.
- Shared custom rendering: inspect its accessibility integration, text editing, graphics behavior and app lifecycle handling.
- Web content: inspect navigation, focus, loading, accessibility and the boundary between web events and native actions.
Choose based on the trial and the team's maintenance responsibilities. A renderer can be appropriate for an announcement but unsuitable for a particular editing workflow. One successful iPhone trial does not establish Android behavior or support for every target offered by a game engine.
Measure the cost before expanding
Remote delivery adds work: fetching definitions, obtaining assets, validating content, rendering and maintaining compatible behavior across installed versions. It may also remove bundled variants. The net effect on binary size, memory and responsiveness depends on the implementation.
Compare the existing screen with the proposed replacement on representative devices. Record cold and warm presentation time, transferred bytes, peak memory, animation frame timing, errors and fallback frequency. Test both an empty cache and a previously used app. Use the same surface and device conditions for each comparison.
Measure operational speed separately: time to prepare, review, publish and verify a supported change. A shorter publication process does not by itself demonstrate better conversion. For experiment planning, use the paywall testing guide; for technical bottlenecks, use the mobile optimization guide.
Where Nuxie fits
Nuxie is a mobile app growth agent that creates and improves Experiences such as onboarding and paywalls inside an existing app. Its SDK guides describe integration for iOS, Android, React Native, Flutter, Unity, Godot and Unreal. Follow the installation and native dependency instructions for your framework and test the target you intend to ship.
The publishing guide separates draft editing from published versions. An update builds while the existing live version remains available; delivery follows its schedule, audience and trigger. After integrating the app, verify a published Experience on an eligible device using Testing in your app.
For a first evaluation, choose one onboarding or paywall change, define the required interactions, and run the compatibility and failure cases above. Keep the app's purchase and access responsibilities explicit. The RevenueCat comparison includes an ownership worksheet for teams considering retaining their existing billing system.
Evaluating onboarding and paywall tools for one of these surfaces? See the Superwall and Nuxie comparison and Adapty and Nuxie comparison for questions to resolve during your vendor trial.
Questions to settle before adoption
Can every change avoid an app release?
A remote definition can use capabilities already present in the installed client. A new native integration, permission, component implementation or unsupported action may require an app release. Include older installed versions in the decision.
Does server-driven UI require replacing the whole app?
You can start with one surface while retaining the existing app shell and other screens. Define how that surface enters, exits and passes results back to the app before expanding it.
What happens offline?
Specify the behavior rather than assuming a cache solves every case. A first installation may have no cached definition, and a cached promotion may have expired. Exercise those cases alongside interruption and reconnection.
How do we know the trial succeeded?
Write acceptance criteria before building it: the intended supported update reaches the right app versions, required interactions work, failure behavior is usable, performance stays within your chosen limits, and the team can recover. Assess growth outcomes separately with a suitable experiment.