a backend-driven UI toolkit for Kotlin Multiplatform — the server describes a screen as a tree of components, the client renders it, and a new screen ships without a new client release

🧃 one annotation → the component is on the wire and in the renderer registry

Backend-driven UI is easy to start and hard to keep honest. The usual failure is a toolkit that knows your components: a sealed hierarchy of every widget the product happens to have, a client that must be released whenever the server learns a new one, and a serialiser that quietly turns an unfamiliar type into a crash.

Kompot is built the other way round. The core knows about a tree, actions, modifiers and tokens — and nothing about what a "product card" or a "story" is. Everything concrete arrives as a plug-in module, and an unknown type degrades to a placeholder instead of taking the screen down.

• open contracts, not sealed sets — KompotComponent, KompotAction, FieldValue and ValidationRule are interfaces; the set of concrete types is assembled by the application;
• generated registration — mark a component or a renderer with @KompotComponentMarker and KSP writes its polymorphic registration and renderer entry;
• open string tokens — a backend may send ColorToken("promo_gold") with no client release; a server-driven theme (kompot-theme) can also say what to paint it with;
• forms that stay client-side — validation, visibility conditions and cross-field rules run locally, and only a server-relevant change asks the backend for a patch;
• live updates — a screen can name its own update channel, per user, across several server instances;
• multi-step flows as pure functions — a wizard graph is (session, transition, draft) -> session, so branching is covered by unit tests with no HTTP, no database and no UI in sight;
• it degrades rather than breaks — an unknown component, an unknown action or a malformed theme token costs a widget or some styling, never the screen.

youndie.github.io/kompot shows the last point live: a body on the left, the screen on the right, and a switch to "a client released earlier" — a component it has never heard of leaves a hole while the rest of the screen stays.

Every module is published to Maven Central under one version; take it once, from the platform, and name no version anywhere else. The badge above shows the latest one.

dependencies {
    implementation(platform("io.github.youndie.kompot:kompot-bom:0.38.0"))

    implementation("io.github.youndie.kompot:kompot-core")
    implementation("io.github.youndie.kompot:kompot-standard")
    implementation("io.github.youndie.kompot:kompot-ktor")
}

Use the platform rather than repeating the version: it constrains every coordinate this build publishes, the per-target ones (kompot-core-jvm, kompot-core-iosarm64, …) included, so no combination nobody built can be written down. Snapshots of main, <version>.<ci run>, are in https://reposilite.kotlin.website/snapshots.

To have registrations generated, apply KSP to the module that declares components — the setup, and why a component and its renderer belong in different modules, are in kompot-registry-processor. A consumer of that module never applies KSP.

Moving up a version and meeting a compile error: UPGRADING.md says what to write instead. kompot is 0.x and promises no stability — only that a break it declared is on that page.

A component is a plain serialisable data class:

@Serializable
@SerialName("product_card")
@KompotComponentMarker
data class ProductCardComponent(
    override val id: String,
    val title: String,
    val onClick: KompotAction? = null,
) : KompotComponent

The server builds a tree and responds with it:

get("/catalogue") {
    call.respondKompotComponent(
        column {
            text("Catalogue", style = TypographyToken("title_large"))
            items.forEach { productCard(title = it.title, onClick = navigate(it.url)) }
        },
    )
}

Through respondKompotComponent, not call.respond: the latter resolves the serialiser from the runtime class and drops the "type" discriminator on the ROOT of the tree, so the client receives an unknown component while every nested child looks fine.

To see the screen without running a client, kompot-preview draws the body an endpoint returns in an IDE @Preview, and kompot-studio opens a build's recorded bodies in an editor with the checks a body has to pass.

form-core, experiments-core and wizard-core know nothing about Kompot components and are usable on their own.

The protocol is written for somebody implementing a server — or a client — in another language:

• kompot-spec/SPEC.md — the rules, including the ones a schema cannot express: degradation, extensibility, forms, pagination, transport, and which changes the other end survives (§15);
• kompot-spec/schema — a JSON Schema per protocol module, generated from the same descriptors that encode a response;
• kompot-spec/types — TypeScript declarations printed from those schemas: an open file for the side that reads bodies, a strict one for the side that writes them. The published kompot-spec jar carries both beside the schemas and SPEC.md, under kompot-spec/types/ — a reader without a JVM takes them out with unzip;
• kompot-tck and kompot-client-tck — the conformance kits for a server and for a client.

Every snapshot of main is also read back from outside by proba, which resolves the published coordinates the way a stranger's build does; the third badge is its verdict on kompot-core, and 1 unchecked is not clean.

• it does not ship YOUR renderers — the standard, form, wizard and image renderers and a Material3 design system are here; a component you invented needs a renderer you write. SwiftUI rendering is yours too;
• it does not choose a transport — the live-update contract is here, SSE or WebSocket is yours;
• it does not validate your business rules — form-core covers what a form can decide locally; limits and balances belong to the server;
• it does not assemble your component set for you — the application composes its own SerializersModule from the generated pieces.

Every protocol module publishes for JVM, Android, the three iOS targets and wasmJs, and every Compose module for the same set minus iosX64, which Compose no longer publishes for. The modules are common code with no expect/actual, so the same screens draw on a desktop, a phone, an iPhone and in a browser.

The Compose half is built against Compose Multiplatform 1.12.1 and material3 1.12.0-alpha03; a consumer on another Compose line compiles and then fails at the first screen, so stay on the same one. On Android every module asks for compileSdk 37.

Three modules are JVM-only on purpose: kompot-ktor and kompot-realtime-server (server helpers) and kompot-forms-standard (a DSL that builds a form on the server).

skills/kompot-layout/SKILL.md is the method for taking a screen from a design canvas to the wire, written as a Claude Code skill; tools/canvas are its measuring instruments.

The repository is a Claude Code plugin, kompot, listed in the kotlin-skills marketplace:

claude plugin marketplace add youndie/kotlin-skills

claude plugin install kompot@kotlin-skills

The skill then appears as /kompot:kompot-layout and triggers on its own when a task matches, and the canvas tools come with it. The plugin's version is in .claude-plugin/plugin.json, and claude plugin update sees nothing else: a change to skills/ or tools/canvas/ raises it, and CI refuses a pull request that does not.

./gradlew build

JDK 25, as a toolchain (the bytecode stays Java 17). On a Mac without an iOS simulator runtime the simulator test tasks fail — install one through Xcode, or skip them:

./gradlew build -x iosSimulatorArm64Test -x iosX64Test

MIT.