Build shared Compose UIs for Android, iOS and the web. Render real HTML in the browser.

Documentation · Shopping demo · Playground · API reference

Domposable is a Kotlin Multiplatform UI library. Write your components and layouts in commonMain, then render them with Compose UI on Android and iOS or semantic HTML on Kotlin/JS. Desktop and Wasm are available as experimental targets.

Start with the included Material 3 controls, adapt them to your brand, and wrap them behind your own component names. Your app keeps its state management, dependency injection and navigation.

Domposable is used in Podiumas, a live sports tournament app. The examples below show smaller features you can explore and reuse.

• Features
• Quick start
• How it works
• Supported platforms
• Examples
• Modules
• Documentation
• Contributing
• License

• Shared components and layouts. Write ordinary Compose functions with your own state and callbacks.
• Real HTML. Use browser links, form controls, headings and page landmarks, styled with CSS.
• Customizable design systems. Set theme defaults and per-control styles. Use an app-owned platform implementation when a control needs different behavior.
• Adaptive layouts. Use available width to choose breakpoints, panes and layout recipes.
• Material 3 controls. Start with standard components and selected expressive variants. Browse the catalog.
• Public-page export. Generate HTML and CSS snapshots of existing public pages at build time. Configure the exporter in Kotlin Gradle with a list of routes. Setup and limitations.
• Optional navigation and screen tooling. Add Navigation 3, browser URL handling or KSP-generated entries when you need them.

Use components directly with Compose state, an existing ViewModel, Metro, Koin or another DI container. You do not need application KSP setup or a screen registry to use the components. Existing frameworks can also reuse the generator with their own annotations and hosts.

The core uses stable Compose Multiplatform. Native controls currently use Material 3 alpha APIs. See tested versions and platform boundaries.

[!NOTE] This README describes main. Choose a published version from Releases. Before 1.0, minor releases may change APIs. Check the migration guide when upgrading.

Add mavenCentral() and google() to your repositories, then replace <released-version> with a version from Releases.

val domposableVersion = "<released-version>"

kotlin {
    sourceSets {
        commonMain.dependencies {
            implementation("io.github.samuolis.domposable:domposable-ui:$domposableVersion")
            // Optional: adaptive layout helpers.
            implementation("io.github.samuolis.domposable:domposable-adaptive:$domposableVersion")
        }
    }
}

The UI artifact includes the shared API and platform implementations. The Material artifact remains a compatibility alias. See the installation guide and tested toolchain for Compose plugins and target setup.

import androidx.compose.runtime.Composable
import io.github.samuolis.domposable.foundation.*
import io.github.samuolis.domposable.material.DomposableMaterialTheme
import io.github.samuolis.domposable.ui.*

@Composable
fun ContactsScreen(onAddContact: () -> Unit) {
    DomposableColumn(
        modifier = DomposableModifier.padding(16.dp),
        gap = 12.dp,
    ) {
        DomposableText("Contacts", style = DomposableTextStyle.Title)
        DomposableButton("Add contact", onAddContact)
    }
}

@Composable
fun App(onAddContact: () -> Unit) {
    DomposableMaterialTheme {
        ContactsScreen(onAddContact)
    }
}

Use Android setContent, iOS ComposeUIViewController, a desktop Compose window or Kotlin/JS renderComposable for HTML. The feature and its callbacks stay in commonMain. The host selects the platform's composition environment. An optional experimental Wasm host is available for Compose UI comparisons.

Platform entry-point examples →

For most apps, setup is simply DomposableMaterialTheme { AppContent() }. The theme supplies appearance values. Shared component calls use direct platform implementations to create controls and connect events to your callbacks.

flowchart TB
    Feature[Shared feature composable] --> Components[Domposable component calls]
    Components --> Platform[Compile-time expect / actual]
    Platform --> Native[Compose UI: Android, iOS, desktop, Wasm]
    Platform --> HTML[Semantic HTML and CSS: Kotlin/JS]

Built-in components use expect / actual directly. There is no component provider to configure. Keep your own names such as AppButton, wrap Domposable controls, and set colors, typography, shapes and styles through the theme. For a different control implementation, use an app-owned platform contract. Follow the component call.

Set brand defaults once. Every argument is optional:

DomposableMaterialTheme(
    colors = brandColors,
    styles = DomposableComponentStyles(
        button = DomposableButtonAppearance(shape = DomposableShape.Circle),
    ),
) {
    FeatureScreen()
}

Use DomposableTheme.styles.button.copy(...) for a local override. Nested themes inherit their enclosing brand values. Styles are composition-scoped, so different parts of an app can use different brands.

Custom cards are shared composition too: use DomposableBox for overlapping image/content layers, a portable gradient for the scrim, and the same theme for controls. Use application CSS when you need it inside a custom HTML renderer. Build a card without CSS · Card and pane demo.

Understand the API → · Customize a design system → · Build adaptive layouts →

Components and adaptive helpers do not depend on the screen registry, navigator or ViewModel adapter. KSP is optional. Your app can use Koin, Metro, another DI container or no DI.

Existing Compose UI widgets cannot run inside an HTML composition. Sharing a feature requires portable component calls or your own native/HTML adapters. Existing Compose UI screens need migration beyond changing imports. Migrate one feature at a time →

HTML and Wasm support optional browser history, hash or path URLs and portable entry-state restoration. HTML collections render all keyed items by default. Columns, rows, grids and tables can opt into bounded windowing.

The HTML target is a client-rendered single-page application built on Compose HTML. It does not require Wasm and does not provide server-side rendering.

The optional public-page exporter captures HTML, metadata and generated CSS at build time for an explicit list of routes, including public event pages. These snapshots can display content before JavaScript starts. This is prerendering, not SSR, and it does not guarantee search-engine indexing. The exporter is available from version 0.22.0.

Compatibility, tested versions and platform boundaries →

• Custom components and modifiers: shared component APIs, app-owned CSS/HTML decoration and native drawBehind. Web adapters can also attach CSS and attributes directly.
• Component parameter reference and modifier signatures: generated from the current API.

Explore large collections →

The fictional Fieldwork shop shares its catalogue, cart and feature composables. On the web it uses real links and form controls, with product URLs such as /domposable/shop/products/canvas-weekender/.

The modular shopping example separates catalog and checkout into API and implementation modules. Metro injects entry-owned ViewModels, a composition local supplies typed navigation, and optional KSP generates feature entries. The screen guide also shows manual registration and direct Navigation 3 integration.

Use the pieces your application needs. All artifacts use io.github.samuolis.domposable:<artifact>:<released-version>.

Bug reports and focused contributions are welcome. Start with CONTRIBUTING.md for local setup, validation and maintainer workflows, or open an issue.

PR checks cover ktlint, detekt, Android lint, JVM/Android coverage floors, required binary API checks, packaged consumers, and functional and screenshot tests for Android, desktop, HTML and Wasm. iOS has compilation, ABI and packaged-consumer checks. Simulator runtime checks are not automatic release gates. CI keeps reports and captures in GitHub Actions artifacts. API baseline changes need compatibility, migration and version-impact notes.

Apache License 2.0. Copyright 2026 Samuolis.