Why

This page is for whoever decides whether HotLayout fits the product: what it is for, how it works, and where its limits are. Read it before you integrate anything; it takes five minutes.

Watch: What is server-driven UI? Explained in two minutes (2 min) and Server-driven UI vs WebView vs over-the-air updates (2 min).

The problem#

A promotion, an onboarding step or a rewards screen changes more often than an app is released. Each change costs a build, a store review and a wait for users to update — and the screen your team designed is not the screen people see until they do.

What the product does#

Your team composes a screen in a browser and publishes it. The publication is a JSON document. Your app holds a renderer that draws that document with the platform's own widgets, so the screen changes when the document does.

1. Compose. A manager builds the screen from widgets, binds them to data your backend already returns, and sets conditions for when each part shows.
2. Publish. The builder validates the document against the contract and against your data dictionary, then releases it. Every publication is kept and can be rolled back.
3. Render. Your app reads the published document — from your own backend or from a direct address, see Delivery options — and draws it in your theme and your user's language.

What makes it different#

A contract, not a canvas. The builder and the renderer read one versioned JSON Schema. Anything the schema can express is a field in the builder; anything it cannot express does not exist there. The builder is not able to produce a document your app cannot draw, and when a document is newer than an installed app, the compatibility policy has already decided what the app does.

A preview that looks for problems. The preview in the builder opens on a narrow phone, lets the manager enlarge the text, switch language and take the data away. Empty states, long translations and missing values are found before publication.

Your backend keeps the data. A published screen carries no user data: it carries paths such as user.firstName. Your backend returns the values for those paths to your own app. With the webhook, your backend also stores the published documents, and nothing about your users passes through us.

What it does not do#

• It is not a way to ship code. A document describes layout, content, conditions and named actions. What an action does — navigation, an API call, analytics — stays in your app's code.
• It does not describe animation. The contract says what to show; how a screen appears is the renderer's business.
• It does not replace your design system. Screens reference tokens; your theme gives them values.
• It does not fetch your data. The renderer takes data from your app; it never calls your backend by itself.

Platforms#

The React and Flutter packages are open source; the native readers for iOS and Android are given to customers on request, with a licence or a trial. All four draw the same published JSON. The contract is platform-neutral: the schema files and the widget reference are what a renderer for another platform is written from.

The builder itself runs in a browser — in the HotLayout admin, or inside your own back-office: see Embedding the builder.

Where to go next#

• A developer: the quickstart for your platform, above.
• A backend developer: the backend guide.
• Everything else: the overview.