Roadmap
Pre-alphaThe registry and the CLI are not published yet.Roadmap

Roadmap

What ships first, and what comes after.

  1. Phase 0 · DoneSpecificationEvery component, behavior and pattern written down: API, states, tokens.
  2. You are here
    Phase 1 · In progressFoundationThe system itself: foundations, core, atoms up to templates, plus the tooling around them.
  3. Phase 2 · PlannedBlocksComplete screens assembled from the components, once the system is stable.
  4. Later · PlannedDepthPatterns, more hooks, device CI and visual tests.

Where we are

The specification is done: every foundation, component, behavior and pattern is written down, with its API, its states and its tokens. Phase 1 turns that into code.

Every component layer of this phase now runs in code: tokens and theme, the four core primitives, Title and Text, the 33 atoms, the three molecules, Passcode and the five templates — each in the stylesheet variant, with a demo screen. What is left of the phase is the other styling variants, standalone mode, axiom init and the CI.

Styling variants

  1. stylesheetbehavior / style split in place
  2. unistylesNext upsame API, other engine
  3. tailwindNativeWind / Uniwind, once the split is proven

Components

  1. Foundationstokens, ThemeColors, Theme, light / dark
  2. CoreSlot, Portal, Overlay, Tappable
  3. HooksuseRefreshControl, useControllableState, useOverlayBackHandler
  4. TypographyTitle, Text
  5. Atoms33 components
  6. MoleculesSearchBar, Attachment, DatePicker
  7. OrganismsPasscode
  8. TemplatesAppBar, BottomTabBar, Tab, ToolBar, Scaffold

Tooling

  1. registry.jsoncomponent manifest, 53 entries
  2. CLIIn progressadd ships, init left to write
  3. Standalone modeone self-contained file, no theme, no dependencies
  4. Demo appIn progressone screen per component and light / dark, variants side by side once they exist
  5. Foundations screencolors, typography, spacing, radius, icons, targets, states
  6. CItypecheck per variant, props parity, lint, tests, builds

Phase 0: specification

Done. The whole system exists on paper first — foundations, core, hooks, the component catalog, the behaviors and the patterns. Nothing gets built twice because the API was decided while writing it down.

Phase 1: the foundation

Styling variants

  1. stylesheet for every item in this phase, with the behavior / style split in place. Shipped.
  2. unistyles. Not started: nothing in the registry has a second variant yet, and the unistyles demo app is waiting with an empty axiom.json.
  3. tailwind (NativeWind / Uniwind), once the split is proven on the first two.

Standalone mode

Not started, and important enough to land in this phase. Today a component arrives with everything it stands on: ask for Tab and you also get the theme, the tokens and the core primitives it imports. That is the right default for an app built on Axiom, and the wrong one for an app that already has its own design system and wants a single component out of the catalog.

Standalone mode breaks that chain. axiom add tab --standalone writes one self-contained file: token values resolved inline, no useTheme, no import outside React Native and the component’s own file. Nothing else is added to the project.

The trade is explicit. A standalone component no longer follows a theme, so light / dark and any restyling are the user’s job, in a file that is already theirs to edit. What Axiom still guarantees is the behavior: the touch targets, the gestures, the states, the safe areas.

It belongs to phase 1 because it is a registry concern before a CLI one. Every entry needs to describe the theme-free form of its component, per styling variant, and that shape is much cheaper to settle now than to retrofit across unistyles and tailwind once they exist.

Components

GroupItemsState
FoundationsTokens, ThemeColors, component tokens, Theme, light / dark, components(colors)Shipped
CoreSlot, Portal / PortalHost, Overlay, TappableShipped
HooksuseControllableState, useOverlayBackHandler, useRefreshControlShipped
TypographyTitle, TextShipped
AtomsAll 33 atomsShipped
MoleculesSearchBar, Attachment, DatePickerShipped
OrganismsPasscodeShipped
TemplatesAppBar, BottomTabBar, Tab, ToolBar, ScaffoldShipped

useOverlayBackHandler was not in the original plan: BottomSheet, Dialog and Menu need to close on a back gesture instead of leaving the screen, so the hook ships in three versions — react-native, expo-router and react-navigation — and add picks one from the project’s package.json.

Tooling

  • registry.json — shipped, 53 entries.
  • CLI — add is shipped, with internal dependencies, icon source, navigation detection and a --watch mode. init is still to write: an axiom.json is written by hand for now.
  • Standalone mode — not started. A theme-free form per registry entry and variant, then add --standalone to write it.
  • Demo app — shipped for the stylesheet variant: one screen per documented item, in 9 groups from Foundations to Templates, and a light / dark switch. Variants side by side wait on the variants themselves.
  • Foundations screen — shipped: colors, typography, spacing, radius, icons, touch targets, states.
  • CI — not started. Typecheck per variant, props parity between variants, lint, tests, builds.

Phase 2: blocks

Complete screens built with Axiom components, once the system is stable: authentication, onboarding, monetization, profile and commerce.

Later

  • Agent integration: the CLI commands an agent needs to find, plan and verify a screen — search, info, plan, doctor, --json output — plus the AGENTS.md, skill and MCP entry points. Specified, not built: add is the only command available today.
  • Patterns: selection mode, search experience, async content state…
  • More hooks: hide-on-scroll, collapsible header, keyboard-aware behavior…
  • CI on Android and iOS devices, screenshots, visual tests (including parity between styling variants), accessibility checks.