Texuli native · in development

The same catalog, rendered by Compose.

One component contract drives both runtimes. The web side ships today: every package is on npm as 0.1.0-next.1. The native side renders Compose through Kotlin Multiplatform and is in development — conformance-tested in this repository, published nowhere yet.

Read the deep dive: why Svelte and Kotlin Why web and native, one contract

What exists today

What ships, what is being built, and what is only planned — stated plainly.

Web runtime: Shipped: All 15 packages are published to npm as 0.1.0-next.1 under the dist-tag next, and texuli.com builds from this repository.
Spec contract: Shipped: One manifest projects both ways today: the TypeScript projection ships in the npm packages, and the Kotlin projection is generated and tested in packages/spec/generated/kotlin/.
Native renderer: In development: A Compose renderer driven by Kotlin Multiplatform: page, document and deck layouts, text lists, boards, tables, media frames and a bounded compact-chart slice. Conformance-tested in this repository against the same semantic goldens as the web.
Maven Central: Planned (ADR-005): Publication under the fixed com.texuli coordinates is planned (ADR-005). Until then the native modules texuli-spec and texuli-compose are consumed in place from this repository — nothing is on Maven yet.

Why Kotlin Multiplatform

The web runtime ships today with Svelte 5. The native renderer is in development, and its foundation is a deliberate choice: Android applications, Compose surfaces, iOS sharing and desktop tooling live in a world where a JavaScript bundle is the guest, not the host.

Why Kotlin wins the native half

One language across the native side. Shared data models, validation and catalog logic compile once per platform instead of being re-written per target.
Compose paints the interface. The renderer paints with Compose Multiplatform, the declarative toolkit the catalog ladder maps onto directly. Compose for the web is not a target, because the web stays Svelte.
First-class tooling. Static typing, multiplatform libraries and IDE support keep the native half held to the same bar as the web half.
It consumes the contract, not the web code. Kotlin never imports Svelte packages; it reads the generated spec. The layer graph stays one-directional.

How the renderer consumes the contract

The seam between the runtimes is the catalog contract: every Texuli component's props, kinds, enums and tiers are declared once in the manifests, generated for TypeScript and Kotlin. On the native side, one pipeline turns a blueprint into painted UI:

loadBlueprint parses and decodes the blueprint into the generated models.
It validates against the spec vocabulary. Invalid structure is refused, never repaired.
It normalizes the result to a render plan: extension props are dropped, and unknown ids become visible placeholders.
BlueprintView paints the plan under TexuliTheme and reports intents to the host.

The theme story is honest too: TexuliTheme is a minimal token theme until texuli-tokens is generated from the spec's token roles (design §3). The values mirror the default Texuli theme's neutral roles, while the engine behind the web's --tx-* contract remains the implemented one.

The renderer's entry point, quoted verbatim: native/texuli-compose/src/commonMain/kotlin/com/texuli/compose/BlueprintView.kt

/**
 * Paint a validated render plan (design §4, step 5). Each id resolves through
 * [NativeRegistry]; anything else paints a visible placeholder. Text is shown
 * as text: nothing in a blueprint is executed or interpreted as markup.
 */
@Composable
fun BlueprintView(plan: List<PlanNode>, onIntent: (TexuliIntent) -> Unit = {}) {
    Column(verticalArrangement = Arrangement.spacedBy(12.dp)) {
        plan.forEachIndexed { index, node -> PlanNodeView(node, "$index", onIntent) }
    }
}

The honest coverage registry, quoted verbatim: native/texuli-compose/src/commonMain/kotlin/com/texuli/compose/Registry.kt

/**
 * The native side of the translation dictionary (design §5): catalog id to
 * native binding. Coverage is reported per id; an id without a binding paints
 * a visible placeholder. A binding never promotes an id to portable core:
 * that needs the audit and passing cross-target conformance.
 */
enum class BindingStatus { IMPLEMENTED, PLACEHOLDER }

Status. In development. The renderer is conformance-tested inside this repository — GoldenConformanceTest loads each golden with loadBlueprint, traces the plan, and must equal the web trace. Nothing is published to Maven Central yet: both modules carry their planned coordinates and are consumed in place (ADR-005).

Read the full argument: Why Svelte and Kotlin The architecture: web and native, one contract

What exists in this repository today

Every claim on this page maps to a path you can open. The native renderer is in development: it runs from this source tree, it is conformance-tested against the web target’s semantic traces, and nothing is on Maven Central yet (ADR-005).

The native modules

texuli-spec: The native contract module: the generated Kotlin models, enums and decoders, plus the strict JSON reader, the blueprint validator and the render plan. Compiles for the JVM and for iOS targets.
native/texuli-spec
texuli-compose: The Compose renderer: the token theme, the native registry and typed host intents, with layout, text, list, table, board, stat, media and compact-chart widgets. Anything outside the documented slice paints a visible placeholder, never silence.
native/texuli-compose
conformance: The native half of the dual-target golden gate: each spec golden must trace identically on web and native, every invalid fixture must be refused with the TypeScript validator’s codes, and six Kotlin Multiplatform app migrations pin each widget’s status.
native/conformance
generated Kotlin projection: The Kotlin projection generated from the same manifests as the shipped TypeScript packages — compiled in place by the native modules, never copied, so both languages stay one declaration apart.
packages/spec/generated/kotlin/com/texuli/spec
native/README.md: The registry this section summarizes: widget statuses, the Kotlin test map, the target graph and the build-health baseline.
native/README.md
semantics.json: The target-neutral semantic rules — role, accessible name and heading level per catalog id — that the web and native traces must both satisfy.
native/conformance/semantics.json

Shipped, in this repository

The Kotlin projection is generated and tested in this repository, from the same manifest data the shipped TypeScript packages are built from.
texuli-spec compiles for the JVM and for iOS (arm64 and simulator targets); texuli-compose and conformance run their suites on the JVM.
The Compose renderer paints a documented slice: page, document, deck, card and grid layouts; text blocks and ordered and unordered lists; static boards; stat and KPI blocks; accessible tables; image, figure, video and gallery media frames; and a bounded compact-chart slice (sparkline, bullet, gauge, progress ring).
The dual-target golden gate passes: GoldenConformanceTest requires each spec golden’s native semantic trace to equal the web trace, and InvalidFixtureParityTest refuses every invalid fixture with exactly the TypeScript validator’s codes.
Six Kotlin Multiplatform app migrations pin every widget’s documented status, from a starter screen to a static game scoreboard.
HostilePropsTest drives wrong types, depth bombs and control strings through every projection: nothing throws, and everything stays in bounds.
The web runtime is published: all 15 packages are on npm as 0.1.0-next.1 under the next dist-tag.

Planned

Planned is not promised: each item lands when its design decision or review does — no dates, no sign-ups.

Maven Central publication under the fixed com.texuli coordinates (ADR-005) is planned. The namespace is verifiable by DNS, but publication wiring still needs the owner’s go — nothing is on Maven Central yet, and both modules stay consumed in place from this repository.
An Android target for the renderer, pending a design decision.
A SwiftUI adapter over the iOS texuli-spec projection, pending the same decision.
Image decoding is planned: data-URI pixels and a host-supplied loader for https and relative sources, plus a conformance golden with media.
App-shell layouts and the remaining chart families are planned — visible placeholders in the renderer today.