Repo and versioning strategy for multi-platform DS

WHAT THIS TESTS Whether you can separate shared, platform-agnostic intent from platform-specific implementation, and choose a versioning scheme that respects differing release cadences.

A GOOD ANSWER COVERS Establish tokens as the platform-agnostic single source of truth, authored once and transformed into platform outputs such as CSS variables, JSON, Swift, and Kotlin via a tool like Style Dictionary. Structure components into per-platform and per-framework packages, for example a React package, a Vue package, and an iOS package, that each consume the generated tokens. Favor a monorepo with workspaces so shared tooling, tokens, and tests live together while packages publish independently. Use independent semantic versioning per package, because a Vue-only bug fix should not force an iOS release. Coordinate releases with a tool like Changesets. Document a parity matrix so consumers see which components exist where.

COMMON WRONG ANSWERS Forcing a single lockstep version across every platform, which couples unrelated release cadences. Duplicating token values by hand in each framework, guaranteeing drift. Putting platform-specific logic in shared token files. Assuming one codebase can target web and native identically.

LIKELY FOLLOW-UPS How do you generate platform outputs from one token source? How do you track cross-platform parity? Monorepo versus polyrepo trade-offs? How do you coordinate a token change that affects all platforms?

ONE CONCRETE EXAMPLE Tokens live in one package and Style Dictionary emits CSS, Swift, and Kotlin artifacts. The React, Vue, and iOS component packages each depend on their generated token artifact. A Vue accessibility fix ships as a Vue patch release without bumping React or iOS, while a brand color change updates the token package and triggers coordinated downstream releases.