Versioning and distributing multi-platform tokens

WHAT THIS TESTS This extends the transform question into distribution: it is not enough to generate files, you must version and ship them so each platform's tooling can consume updates. The interviewer checks end-to-end thinking.

A GOOD ANSWER COVERS Store tokens as JSON in a single source repo, following the W3C DTCG format for portability. Transform with a tool like Style Dictionary, configuring a platform per target that applies the right transforms and emits CSS custom properties or a JS module for web, colors and dimens XML for Android, and a Swift file or asset catalog for iOS. Apply semantic versioning so consumers understand the blast radius of a change. Distribute through each ecosystem's package manager: publish an npm package for web, a Maven or Gradle artifact for Android, and a Swift Package or CocoaPod for iOS. Run the whole flow in CI on merges to the tokens repo: build all outputs, bump the version, tag, and publish each package, with a changelog noting breaking changes.

COMMON WRONG ANSWERS Generating the files but stopping there, leaving teams to copy outputs manually. Using one version scheme but no real distribution channel per platform. Ignoring how breaking changes ripple, so consumers get surprised by a major bump.

LIKELY FOLLOW-UPS How do you signal breaking token changes to consumers? How do mobile teams pull updates compared to web? How do you keep all three packages on the same version?

ONE CONCRETE EXAMPLE A merge to the tokens repo triggers CI: Style Dictionary builds web, Android, and iOS outputs; a release step bumps to 3.1.0 under semantic versioning; then it publishes @ds/tokens to npm, the Android artifact to an internal Maven repo, and the iOS Swift Package tag. Each platform's dependency manager then pulls 3.1.0, and a changelog flags that renamed tokens would have required a major bump instead.