HotLayout — integrator documentation

HotLayout is server-driven UI: your team assembles a screen in a visual builder and publishes it as JSON, and your app draws it with a renderer package — so a screen changes without an app release.

This documentation is for the people who connect the two: the developer of the mobile or web app, the backend developer, and whoever reviews the integration for security.

Start here#

Videos#

• Ship screens, not releases (2 min) — the product overview.
• What is server-driven UI? Explained in two minutes (2 min)
• Server-driven UI vs WebView vs over-the-air updates: how to change an app without a release (2 min)
• Where your users' data lives — HotLayout for banks and fintech (2 min)
• React quickstart — render a server-driven screen with one component (3 min)
• Actions, analytics and data in your code (3 min)

How the pieces fit#

 builder ──publish──▶ document (JSON) + theme (JSON)
                          │
          webhook to your backend, or a direct address
                          │
                          ▼
 your app:  renderer( document, theme, data from your backend ) ──▶ screen

The words mean the same on every page: a document is what is published, a renderer is the package that draws it, the host is your app around the renderer.

The packages#

Both are open source and draw the same JSON.

There are also native readers, which draw the same JSON too:

The native readers are not open source and are not in a public registry; write to contact@hotlayout.com to ask for access.

All pages#

Decide

• Why — what the product does and what it deliberately does not do.

Integrate

• Quickstart for Flutter — from an empty app to a published screen on a phone.
• Quickstart for React — the same for a Vite or Next.js app.
• Quickstart for iOS — the native reader for Swift and SwiftUI (available on request).
• Quickstart for Android — the native reader for Kotlin and Jetpack Compose (available on request).
• Delivery options — how a published screen gets from the builder to your app: a signed webhook or a direct address.
• Backend guide — the data your backend returns, how to accept a publication, how to serve versions.
• Embedding the builder — the <hotlayout-builder> element in your own back-office.

Understand

• Data dictionary — the fields and lists your backend promises to every screen.
• Theme — tokens, values and how a rebrand ships without a release.
• Localization and RTL — languages inside a document and right-to-left scripts.

Look up

• Widget reference — every widget and property, generated from the contract.
• Compatibility policy — what a renderer does with a document it does not fully understand.
• Contract changelog — what each contract version added.

The contracts#

Everything here rests on versioned artifacts. Each has its own version, because a rebrand does not add widgets and a new widget does not change a palette.

The builder cannot produce a document that breaks the screen schema, and it checks every data binding against the dictionary before a publication leaves.

Where the files are. The four JSON files, and the shared tables of cases (fixtures/…) that other pages refer to, are in the repository of the Flutter package, in assets/contract — in the repository, not in the package you install from pub.dev or npm. A file name on these pages — screen-schema.json, fixtures/locale/locale-cases.json — is a path inside that folder. Your project's own data dictionary is downloaded from the admin; see Data dictionary.

Questions#

Write to contact@hotlayout.com.