Distributing design tokens across web, iOS, and Android
cross-platform token pipeline design.
keep one source-of-truth JSON, transform with a tool like Style Dictionary, emit per-platform formats (CSS vars, Swift, XML) in CI.
What's really being asked
This evaluates whether you understand design tokens as a build-and-distribution problem, not just a list of variables, and whether you can keep three platforms in sync.
The full answer
Establish a single source of truth: tokens authored once in platform-agnostic JSON, ideally following the W3C Design Tokens format with explicit types like color and dimension. Run a transformation tool, commonly Style Dictionary, that reads that JSON and emits platform-native artifacts: CSS custom properties for web, a Swift file of static constants or a UIColor extension for iOS, and colors.xml plus dimens.xml for Android. The transform layer handles type conversions, for example hex to UIColor RGBA, pixels to dp, and naming conventions per platform. Wire this generation into CI so a token change produces a versioned release, and distribute outputs as packages each platform depends on, an npm package for web and native artifacts via their package managers.
The mistakes people make
Maintaining a separate color and spacing definition in each codebase, which guarantees drift the moment one platform updates. Treating tokens as design-only and hand-copying values into code. Skipping types, so a transformer cannot correctly format a color versus a dimension.
What usually comes next
How do you handle semantic versioning? Treat token changes like an API: patch for value tweaks, major for renames or removals. How do you support theming? Author base and theme token sets and generate themed outputs, or emit references for runtime switching on web. How do designers contribute? Sync from a design tool export into the JSON source so the pipeline starts at the design file.
A concrete example
A token color.brand.primary with value #0052CC lives in tokens.json. The build emits --color-brand-primary: #0052cc; in tokens.css, a Swift static let colorBrandPrimary = UIColor(red:0, green:0.32, blue:0.8, alpha:1), and a colors.xml entry color_brand_primary. A designer changes the hex once; CI regenerates all three artifacts and publishes new package versions, so web, iOS, and Android pick up the identical color without anyone editing platform code by hand.
Interview question
What is the central reason to run tokens through a transformer like Style Dictionary rather than defining them per platform?
- a.A single JSON source generates synchronized native outputs, eliminating driftCorrect
- b.It lets each platform team own its own color values independently
- c.It makes CSS files load faster at runtime
- d.It removes the need for design tokens entirely
Why? this is the answer
One authoritative source transformed into per-platform artifacts keeps web, iOS, and Android in sync automatically. Per-platform ownership (option B) reintroduces exactly the drift the pipeline is built to prevent.
Just read this? Test yourself on what you have been reading.
Read the original → designtokens.org
- #design-tokens
- #style-dictionary
- #cross-platform
- #ci
- #design-systems
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on design-tokens — each one lists the topics its interview covers.
See open roles