Supported platforms

KinetixUI is a shared design language — one token contract, one set of component contracts — with a native implementation per platform. It is not one framework's code ported everywhere: the SwiftUI, Compose and Flutter libraries are idiomatic to their platforms and are not wrappers around the web components.

This page states what exists and how it is checked, and it does not list anything that isn't implemented. Component counts and the gaps below are generated from components.manifest.json; the verification column is written by hand from each platform's CI workflow, which is named in the row so it can be checked.

• Web · React

  React + Radix + Tailwind98 of 98 components

  Package · distribution

  @kinetixui/uinpm, and source via npx @kinetixui/cli add

  Tokens

  CSS variables, Tailwind preset, typed TS object

  Dark mode

  Yes — `.dark` class

  RTL

  In progress — logical properties plus `KinetixDirectionProvider`

  Automated verification

  Unit, interaction and keyboard tests; axe in jsdom and in a real browser (light + dark); contrast, RTL, typography and grid guardrailsci.yml, a11y-browser.yml

• Web · Angularpreview

  Angular (standalone components, signal inputs)43 of 98 components

  Package · distribution

  @kinetixui/angularnpm — versioned independently of @kinetixui/{tokens,ui,cli}

  Tokens

  The same generated CSS custom properties as React — one stylesheet, no Angular-specific token set

  Dark mode

  Yes — the same `.dark` class contract

  RTL

  Tabs resolve arrow-key direction from the document; the rest not audited

  Automated verification

  ng-packagr AOT build with strictTemplates (every template compiled), plus Vitest behaviour tests for roles, keyboard, disabled state, forms integration and RTL. No browser-level axe pass yetci.yml

• iOS · SwiftUI

  SwiftUI (Swift package)90 of 98 components

  Package · distribution

  KinetixUIFrom a repository checkout — not published to a registry yet

  Tokens

  Swift enums: colors (light + dark), type styles, spacing, radius, motion

  Dark mode

  Yes — follows the system color scheme

  RTL

  Not audited yet

  Automated verification

  swift build and swift test on macOS: WCAG contrast of the light and dark colour sets, and the spacing / radius scale. No view-level interaction or accessibility tests yetnative-swiftui.yml

• Android · Jetpack Compose

  Jetpack Compose90 of 98 components

  Package · distribution

  com.kinetixui:ui-composeFrom a repository checkout — not published to a registry yet

  Tokens

  Kotlin objects and `dimens.xml`: colors (light + dark), type styles, spacing, radius, motion

  Dark mode

  Yes — follows `isSystemInDarkTheme()`

  RTL

  Core controls tested (Tabs mirror); the rest not audited

  Automated verification

  gradle assembleDebug, lintDebug and Compose UI tests (Robolectric) for the core controls: interaction, accessibility semantics, RTL. No screenshot tests yetnative-compose.yml

• Flutter

  Flutter widgets90 of 98 components

  Package · distribution

  kinetix_uiFrom a repository checkout — not published to a registry yet

  Tokens

  Dart classes: color scheme (light + dark), type styles, spacing, radius, motion

  Dark mode

  Yes — follows the platform brightness

  RTL

  Core controls tested (Switch mirrors, RTL build); the rest not audited

  Automated verification

  flutter analyze, widget smoke tests (~55 widgets, light and dark), and interaction, accessibility-semantics, RTL and large-text tests for the core controls. No golden tests yetnative-flutter.yml

Availability, package maturity and verification are three different things#

They were once one word, and the word being printed was the one nothing backed up. Keep them apart:

• Availability — is there an implementation here? A component either has one on a platform, or has guidance in its place (a native equivalent, a composition, or a planned port). Only an implementation counts as coverage.
• Package maturity — is this platform's package a finished product? A product decision about the offering, not a measurement. @kinetixui/angular is Preview because its catalogue is knowingly incomplete; the others are Stable packages.
• Verification — what automated tests actually prove about an implementation. Measured, from the test files, and never inferred from either of the other two. A file called Button.swift existing proves that the file exists.

@kinetixui/ui is a Stable, published package whose catalogue is verified to Beta. Both are true, and one word cannot say both.

Evidence is shown as a fraction, never a tick, because a check mark beside a partially covered catalogue would be the most misleading thing on this page. Catalogue verification is the weakest component on that platform, not an average — a well-tested Button cannot compensate for an unverified Dialog, since you will apply the figure to whichever component you are about to use. Individual components often sit above their platform's floor; each component's page shows its own level.

How a verification level is earned#

Every positive result traces to a source. The evidence is derived from the test files themselves — each marked passage declares what kind of verification it performs, and the components it covers are read from the KinetixUI symbols that passage calls — so a test that is deleted stops counting on the next run. pnpm platform:matrix --verification=<component> prints the file and line range behind every tick.

Nothing is verified Stable today: that rung additionally requires RTL, large-text and visual-regression evidence per component, and a published package.

Reading the table#

• Components counts the components each platform implements, out of 98 in the manifest. React is the reference implementation; the native ports mirror its API where it makes sense on the platform.
• Automated verification is what the platform's CI actually runs. It is the honest measure of how proven a platform is: React has behavioural, keyboard and accessibility tests across the whole library. The native libraries are compiled in CI, and Flutter and Compose now also test their five core controls (Button, Checkbox, Switch, Toggle, Tabs) for interaction, accessibility semantics and RTL; SwiftUI tests its colour contrast and spacing scale but not yet its views. No native port has screenshot tests, and the remaining components on each are compile-checked only — so read them as less proven than React.
• RTL — "not audited yet" means exactly that: each native platform has its own layout-direction mechanism (LocalLayoutDirection, the layoutDirection environment value, Directionality) and it hasn't been checked. See RTL.
• Maturity. Each component is marked 97 stable, 1 beta in the manifest, but per component, not per platform. Given the verification gap above, that label describes the React implementation. Per-platform maturity is a 1.0 task.

Not on every platform, on purpose#

Not every component belongs on every platform, and parity isn't a goal. These are the deliberate gaps on the catalogue-complete platforms, with what each component's page shows in place of a port and the repository's reason for it. Neither a native equivalent nor a composition is counted as platform coverage anywhere on this site — that is what keeps the numbers above meaning one thing.

Angular's gaps are a different kind and are listed separately, by delivery wave, on Angular: its catalogue is still rolling out, so a gap there is unbuilt work rather than a decision.

Not supported#

These are platforms people reasonably ask about. The repository has no implementation of any of them, so none is given a status:

Where to go next#

• Foundations — the grid, radius, elevation and motion behind every platform.
• Angular — the preview web implementation, its delivery waves and what Stable would require.
• SwiftUI, Jetpack Compose, Flutter — installation and usage for each native library.
• Tokens and Theming — the color and type contract.
• Contributing — the platform rule for new components, and what every platform tab has to show.