Token build pipeline for multi-platform output

WHAT THIS TESTS The interviewer wants a concrete transformation architecture: one source, many platform outputs, automated. The key insight is that you transform, never hand-duplicate.

A GOOD ANSWER COVERS Keep tokens as the single source of truth in platform-neutral JSON, ideally following the W3C Design Tokens Community Group format. Run them through a build tool such as Style Dictionary (or Theo) that applies platform-specific transforms and formats: it converts a hex value into an Android color resource, into an iOS UIColor or SwiftUI Color, and into a CSS custom property, and converts unitless sizes into px, dp, or pt as each platform expects. Configure one transform group and format per target so a single source emits ds.css, colors.xml, Tokens.swift, and a JSON build artifact. Wire it into CI so any token change regenerates all outputs, then publish versioned packages per platform with semantic versioning.

COMMON WRONG ANSWERS Maintaining a separate handwritten file per platform, which drifts the moment one platform is edited. Doing transforms manually or with ad-hoc scripts that nobody maintains. Forgetting unit and color-format conversions, shipping web px straight into Android.

LIKELY FOLLOW-UPS How do you handle references and aliases between tokens? How do you version and distribute the per-platform packages? How do you validate the JSON against a schema in CI?

ONE CONCRETE EXAMPLE Your tokens/color.json defines color.primary = #0A74FF. Style Dictionary runs with a web platform emitting --color-primary: #0A74FF, an android platform emitting a color resource with name color_primary, and an ios platform emitting a Swift constant. A CI job runs the build on every merge to the tokens repo and publishes @ds/tokens-web, the Android artifact, and the iOS package, each tagged with the new version.