Kinetixui Library.

ClientKinetix / Open-source
RoleFounder — Design & Engineering
TeamOpen to contributions
Timeline2026 — ongoing (beta)
PlatformReact, SwiftUI, Compose, Flutter
Visit kinetixui.com
KinetixUI homepage — 'One token architecture, in motion across every platform'

The brief.

Every product I'd shipped that spanned web and native ended up with the same quiet tax: a button re-built by hand in React, then again in Swift, then again in Kotlin, each one drifting a shade further from the Figma file every quarter. Dark mode diverged first, then spacing, then which shade of "primary" a given screen actually used.

I set myself the brief I'd have given a client: one design source, no re-implementation, no drift — and it has to hold up under a real accessibility standard, not just look consistent.

"Change the token once. It propagates everywhere, or the system has failed."

The idea.

KinetixUI compiles a single DTCG token source — extracted straight from the Figma file — through Style Dictionary into CSS custom properties, a typed TypeScript object, and native colour and type sets for SwiftUI, Jetpack Compose and Flutter. Every one of the 72 components is styled only against that semantic layer, never a hardcoded hex, so a token edit re-skins the button on all four platforms at once.

Installation works like ownership, not dependency: a first-party CLI (npx @kinetixui/cli add button) resolves a component's registry entry and writes the real source into your project — the same model shadcn popularized — rather than locking you to a version behind a black-box import.

The component registry — 72 components across 7 categories, tagged by platform
Blocks — whole sections composed from the registry, with a Compose and Flutter equivalent for each
Step 01 · Token engine

One source, four outputs.

Colour ramps, spacing, radius and type all start as DTCG tokens pulled from Figma variables, then run through Style Dictionary once per theme. Light and dark aren't a flip of each other — dark never existed in the source file, so it's synthesized as its own independent palette, checked against the same contrast bar as light.

Step 02 · Registry & CLI

Copy the code, own the code.

Every component ships a canonical React implementation plus illustrative SwiftUI, Jetpack Compose and Flutter snippets, one keyed map so there's a single source of truth per platform. The CLI and a shadcn-compatible JSON registry both read from it — add button resolves dependencies and writes it straight into your tree.

Step 03 · Data viz

Charts that re-theme for free.

Thirty-six chart recipes wrap Recharts and draw every colour from the --chart-1…8 tokens, so a palette change reaches the dashboard along with the buttons. Each cartesian recipe carries keyboard data-point navigation and a screen-reader table alternative, not just a canvas.

Step 04 · Accessibility, gated

Trust the audit, not the vibe.

A script resolves every semantic colour pair, light and dark, and checks it against WCAG AA before anything ships — CI fails the build on a regression instead of catching it in a design review. The docs site is the proof: built entirely on @kinetixui/ui and @kinetixui/tokens, in the same themes it documents.

The colour system — seven brand ramps plus a synthesized neutral, every token tagged AA/fail
A component's Code tab — React, HTML, iOS, Android and Flutter snippets from one registry entry
Charts — Recharts-backed recipes driven entirely by the chart tokens
Docs — the introduction page, built on the library it documents

The ship.

KinetixUI shipped as three published npm packages (@kinetixui/tokens, @kinetixui/ui, @kinetixui/cli) sharing one version line, released through Changesets on every merge to main; a Gradle package for Jetpack Compose, a SwiftPM package for SwiftUI and a Dart package for Flutter, each compiled and tested per-platform in CI; and kinetixui.com itself — docs, component gallery, colour system, chart gallery and a theme builder — built entirely on the library it documents.

The four-platform rule is enforced, not aspirational: a component isn't considered done until it exists on all four surfaces or is a documented exception, and CI fails the build if the generated token output or registry drifts from source.

What shipped.

72
Components
Built once in React, ported 1:1 to SwiftUI, Jetpack Compose and Flutter — ~68 with full native parity today.
4
Platforms, one contract
React, SwiftUI, Jetpack Compose and Flutter, all re-themed by editing the same token source.
0
Runtime dependencies
Components are copied into your codebase via the CLI, not installed as a version you don't control.

What I'd do again.

Synthesize dark mode as its own palette, not a mirror. The source file never had one — flipping lightness on the light ramp read muddy and failed contrast in exactly the places focus rings and destructive actions needed it most. Building an independent dark palette from the start cost more upfront and paid it back every theme since.

Audit the auditor. The contrast-check script that gated every release had a resolver bug silently skipping one token pair — and the docs page cited that same script as proof everything passed. A script you trust for compliance needs its own review, not just a green check mark.

Ownership is the feature, not a footnote. Letting people copy a component's real source in, instead of importing a black box, turned "can you customize this one button" from a fork-the-library problem into a one-file edit.

Next case
Reportage