How one Figma token becomes SwiftUI, Compose, Flutter and CSS

One Figma variable, brand/base, becomes var(--ap-brand-base) in CSS, Color.apBrandBase in SwiftUI, AppetiteTheme.colors.brandBase in Jetpack Compose and apBrandBase in Flutter. All four come from one JSON file in the W3C Design Tokens format, compiled by Style Dictionary v5, and three of the four names are stored on the variable in Figma, so the name a designer picks is the name a developer types.

Appetite UI is a Figma UI kit for iOS and Android apps, built like a design system. One token source drives Apple and Material components in light and dark mode, and exports to SwiftUI, Jetpack Compose, Flutter and CSS. This article follows one of its tokens through that export, with the values the code output docs print.

A design token is a named value that lives in one place and is read everywhere else: a variable in Figma, and a custom property, a static constant or a theme field in code. #155DFC in a handoff note says nothing about where it belongs. brand/base says what the value is for, and when the value changes, nothing that reads the name has to change.

In Appetite UI, brand/base is a semantic token that points at a primitive, colors/blue/500. Components bind to semantic tokens only, so a component never names a color (introduction).

The token file is JSON in the format of the W3C Design Tokens Community Group. Its first stable version, 2025.10, was published as a Final Community Group Report on October 28, 2025, and the announcement lists Figma, Style Dictionary, Tokens Studio and Penpot among the tools that support it.

The specification is split into modules. The Format Module defines a token as an object with a $value, a $type unless its group already sets one, an optional $description, and an optional $extensions object where tools may keep data of their own. A reference to another token is its path in curly braces, {colors.blue.500}. Themes such as light and dark live in a second document, the Resolver Module, which describes them as modifiers with named contexts.

Style Dictionary, the build tool the export runs on, has had first-class support for the format since version 4. Its own page says full support for 2025.10 is still work in progress in v5. One difference shows in the sample below: the file writes a color as a hex string, the form Style Dictionary v5 compiles, while the 2025.10 report defines a color as an object with a color space, its components and an optional hex.

The docs print the smallest file that shows the whole idea: one primitive, one semantic token and one reference between them.

{
  "colors": {
    "blue": {
      "500": { "$type": "color", "$value": "#155DFC" }
    }
  },
  "brand": {
    "base": { "$type": "color", "$value": "{colors.blue.500}" }
  }
}

colors.blue.500 is the only place #155DFC is written. brand.base holds a reference to it. Figma writes the same path with slashes, brand/base, and the JSON writes it with dots: the same token in two notations, and the export is where they meet.

The full source carries the file's 6 collections, each with its own modes. A mode is a second value on the same token, which is why Light and Dark, Brand and System, and the three device modes all fit in one source:

Figma lets a variable carry code syntax: one name per platform, Web, Android and iOS, entered in the Edit variable dialog. Dev Mode prints those names in its code snippets, which Figma supports for variables in CSS, SwiftUI and Compose.

Every variable in Appetite UI stores its own code name for all three platforms, and the export reads the names off the variable. AppetiteTheme.colors.brandBase reads like Compose because it was written as Compose, once, on the variable. Since release 2.4 the Platform Bridge roles, the Apple and Material slots, carry SwiftUI, Compose and CSS syntax too (changelog).

Figma has no slot for Dart, so the Flutter name, apBrandBase, is the one name in the set that the export derives instead of reading it off the variable.

I keep the names on the variables so there is one place to change them. When a name changes, the next export carries it, Dev Mode shows it the same day, and nobody maintains a mapping table between the design file and the codebase.

Style Dictionary reads the JSON, resolves every reference to its final value and writes one output per platform. The code output docs and the tokens page cut the output to three tokens so the four languages sit side by side: a color, a spacing step and a duration.

:root {
  --ap-brand-base: #155DFC;
  --ap-space-4: 16px;
  --ap-duration-fast: 120ms;
}

extension Color {
  static let apBrandBase = Color(
    red: 0.082, green: 0.365, blue: 0.988)
}
enum AppetiteSpacing { static let space4: CGFloat = 16 }
enum AppetiteMotion { static let durationFast = 0.12 }

internal val BrandBase = Color(0xFF155DFC)
internal val Space4 = 16.dp
internal val DurationFast = 120

// read as AppetiteTheme.colors.brandBase

const apBrandBase = Color(0xFF155DFC);
const apSpace4 = 16.0;
const apDurationFast = Duration(milliseconds: 120);

The rows below are brand/base, spacing/4 and motion/duration/fast: the same three values, each in the platform's own unit.

SwiftUI writes a color as three components between 0 and 1: 0x15 divided by 255 is 0.082, 0x5D is 0.365 and 0xFC is 0.988. Compose and Flutter write the same hex with the alpha first, FF for fully opaque. The spacing step stays 16 everywhere because each platform counts in its own density-independent unit: CSS pixels, points on iOS, dp on Android and logical pixels in Flutter. The duration changes its number, because SwiftUI animations take seconds and Compose takes milliseconds.

The samples above show one value per token, the Light one. With both modes, the CSS output keeps one custom property and writes the Dark value into a prefers-color-scheme block:

:root {
  --ap-brand-base: #155DFC;
}

@media (prefers-color-scheme: dark) {
  :root { --ap-brand-base: #2B7FFF; }
}

brand/base points at colors/blue/500 in Light and at colors/blue/400 in Dark, and the export writes both hexes under the one property. Nothing that reads --ap-brand-base knows it has two values: the browser picks one from the system setting, which MDN describes as the user's request for "light or dark color themes".

Each platform keeps a second value in a place of its own, and a color with two modes has to arrive there to follow the system setting:

Apple puts the SwiftUI and UIKit row in one sentence: a color object created from a color asset "loads the color variant that matches the current environment settings". How a mode is designed in Figma, and why the Dark value of brand/base is a different blue, is in Dark mode with Figma variables, not duplicate frames.

Each platform already has a model for type and motion, and the output writes into it. The SwiftUI output sets type on Dynamic Type text styles, and the Compose output includes a ready Material 3 typography object (FAQ). Apple defines a text style as "a dynamic text style to use for fonts": its size follows the reader's text size setting at runtime, which a Figma file cannot show. The typography docs read every size as the default size class for that reason.

In the file, the Platform Bridge points iOS body at fontSize/lg, 18, and Material bodyLarge at fontSize/base, 16. It carries the size only: line height, weight and tracking stay on the Appetite UI side (Platform Bridge).

Easing curves need the least translation. motion/easing/standard holds cubic-bezier(0.2, 0, 0, 1): CSS reads it as written, and the same four numbers are the arguments of SwiftUI's timingCurve, Compose's CubicBezierEasing and Flutter's Cubic. Durations change their number, as the table above shows, and springs are the part the web cannot take (motion docs).

A token set that exports to four platforms holds values one of them cannot express. Appetite UI marks four kinds where a developer will look:

The effects docs give the instruction for the first row in one line: "Use liquidGlass in the file, reach for the platform's own glass material in code, and treat the token as a Figma instruction rather than a web spec." The state opacities are numbers on purpose. They describe a layer Material draws over a component, and iOS has no such layer to give them to.

A variable in the file carries a written description of its job next to its value. brand/base says "Primary buttons, active states, links. Maps to iOS tint and M3 primary." The file you buy ships a context pack, tokens.md and tokens.json, and the Appetite UI Core Skill, included with it, tells Claude, Cursor or any agent that reads project instructions which token to reach for (AI).

A generated screen and a compiled build then read the same names from the same source. The longer version, with the Core Skill and the Figma MCP, is in How Appetite UI works with AI agents: Claude, Cursor and the Core Skill.