Design Tokens: One Source of Truth, Figma to React Native

If you ship a mobile app, you have probably lived this scene: the Figma file says #3B82F6 for the primary button, the React Native code has #3B82F6 in one component and #3A82F7 in another, and the deployed build ended up #3B82F0 after one engineer "matched it to the screenshot." Two days later the brand team wants the blue deeper, and you are touching six files across three platforms to change one color. That gap between design intent and shipped code is exactly what design tokens are built to close, and Dolfy.ai treats them as the single source of truth across its 5-step Design OS — tokens are how the product, the screen, and the exported React Native code stay honest with each other.

Key Takeaways

• A design token is a named design decision (a color, a spacing value, a radius), not the value itself, and that name is the contract between Figma, your code, and your shipped app.
• A token system only works when Figma Variables, the codebase, and the running React Native build all read from the same definitions — that is the "single source of truth" idea in plain English.
• For mobile teams, tokens are what keep iOS, Android, and web from drifting apart across releases, especially when Tailwind CSS and TypeScript types are involved.
• Dolfy.ai's Design Foundation step bakes tokens into the workflow before screen work starts, so the export is production-ready React Native + Tailwind + TypeScript, not a hand-rebuilt mock.

What are design tokens and why do teams treat them as a single source of truth?

In plain English, a design token is a named value that represents a design decision. The name is the contract. Instead of writing #3B82F6 in twelve different files, a team writes color.brand.primary, and every consumer of that name (a Figma Variable, a Tailwind utility, a React Native style object) gets the same value from the same place.

That is what "single source of truth" means in design systems. It is not a metaphor. It is a practical rule: every color, spacing step, radius, font size, and elevation in the product should be defined once and consumed everywhere. The W3C Design Tokens Community Group has been standardising this since 2019, with a published spec that defines tokens as machine-readable, structured data with a name, value, type, and description (W3C Design Tokens spec). The reason a spec exists at all is that teams kept losing this war with copy-paste values.

A useful way to think about it: the Figma file is not the source of truth and the codebase is not the source of truth — the token definition is. Figma Variables can sync to a JSON file, that JSON can feed a transformer like Style Dictionary, and the output can be Tailwind config, TypeScript constants, or iOS/Android resource files. When the brand blue changes, you change one line. When an engineer accidentally hardcodes a hex value in a screen, it shows up in code review as a clear violation of the system.

How do design tokens move from Figma into React Native code?

The pipeline is shorter than it looks, and it is the part most teams underestimate.

In Figma, you define Variables (or use a plugin like Tokens Studio) to express your tokens: color/brand/primary, spacing/4, radius/md, font-size/lg. Those Variables are exported, usually to a JSON file, and a transformer (the most common one is Amazon's open-source Style Dictionary) turns the JSON into platform-specific outputs. For a React Native + Tailwind project, that means a Tailwind config, TypeScript type definitions, and a plain tokens.ts module your components can import.

The shift that matters is the direction of flow. In an old workflow, the developer reads the Figma file and writes styles. In a token workflow, the developer imports the token, and the token is the same artefact the designer is editing in Figma. The Figma file and the code are two windows into the same database, not two independent sources of truth that have to be kept in sync by hand. That is the only way an AI app design tool can ship production-ready React Native output without the design getting quietly re-interpreted by every developer who touches it.

Why do mobile app design systems break without shared tokens?

They break because mobile is a multi-platform problem in disguise. A single product is usually an iOS build, an Android build, a marketing site, and an Expo Web preview. Without a token system, each of those surfaces ends up with its own near-identical value set, and "near-identical" is the most expensive state a UI can be in.

A 2020 Forrester Total Economic Impact study on design systems (composite organisation) found a 244% ROI over three years and a payback period of less than 7 months, with concrete savings coming from faster design and dev cycles, reduced rework, and lower onboarding costs for new engineers (Forrester TEI of Design Systems). The IBM Carbon Design System has publicly reported that the company has used the system to standardise more than 350 web properties and cut design debt dramatically, which is a useful real-world signal of why the "one source" framing matters at scale (IBM Carbon).

The failure mode for mobile is more specific. A button radius of 8px becomes 8, 8, 8.5, and 12 across screens. A spacing scale gets improvised ("just push this down 6 pixels") and now your grid has seventeen different gaps. Accessibility rules — a minimum tap target of 44×44 on iOS, 48×48 on Android — slip because no one remembered to encode them. Tokens fix this not by being clever, but by removing the option to improvise. There is no 8.5. There is radius/sm, radius/md, radius/lg, and that is the menu.

What does a single source of truth actually look like day to day?

It looks deceptively boring, which is the point.

A small, well-shaped token file might look like this in spirit: color.brand.primary points to #3B82F6, color.surface.default points to #FFFFFF, spacing.4 is 16px, radius.md is 8px. That is the entire dataset. Everything else in the product is a reference to those names.

In Figma, those are Variables. In a Style Dictionary pipeline, those are the source JSON. In the codebase, those are TypeScript constants and Tailwind utilities (bg-brand-primary, p-4, rounded-md). In the running app, the same names show up in the React Native style sheet. When a designer changes color.brand.primary in Figma, the design file updates, the JSON updates, the Tailwind config updates, the TypeScript types update, and the next build shows the new colour. The product manager can see it in the Web preview, the developer can see it in the Expo Go QR preview on a real device, and nobody has to send a screenshot saying "this blue looks wrong."

The boring part is the discipline: nothing in the codebase is allowed to use a raw value. The interesting part is what that discipline buys you — speed, consistency, and the ability to change the product without re-engineering it.

How can AI design tools like Dolfy keep tokens consistent across the stack?

The honest answer is: only if the tool is built around a system, not a single prompt.

That is the practical difference between a design toy and a design workflow. A single-prompt generator can produce a beautiful screen, but it has no memory of the tokens behind that screen, so the next screen it generates will use slightly different spacing, slightly different colour, slightly different radius. The result is a stack of inconsistent screens that still has to be reconciled by hand.

Dolfy.ai is built around a 5-step Design OS — Product Definition, Data Model, Design Foundation, Screen Design, Export — and the Design Foundation step is where tokens, type scale, colour scale, spacing scale, and component primitives are defined before any screen is generated. Because that foundation exists, the Screen Design step is constrained by the same token system the export will use. When Dolfy exports production-ready React Native + Tailwind components with TypeScript types, it is exporting components that already read from the same token source the design uses.

Dolfy's specialised AI agents reinforce this. The UI Architect agent focuses on system-level decisions (component patterns, layout rules, token usage) and the Product Manager agent focuses on product framing, so the work that happens before the screen is generated is structured, not improvised. For a solo founder or a small mobile team, that is the practical value of an AI app design tool with tokens at its core: you get the speed of generation without losing the consistency a human design system would normally take months to build.

How do you roll out design tokens on an existing React Native project?

You start by admitting how many values you actually have. Open three of your busiest screens and count the distinct colours, spacing values, and radii in the code. Most mobile apps, audited honestly, have 40–80 unique colour values, 15–25 spacing values, and 8–15 radii — and most of those are accidental, not designed.

The practical rollout looks like this:

1. Audit and cluster. Group the values you actually use into semantic categories (brand, surface, text, spacing, radius). Aim for a small, named scale, not a flat list.
2. Pick a token format. JSON is the most portable starting point. If you are already using Tailwind, plan to feed tokens into tailwind.config.js; if you are using NativeWind, the same tokens become a theme.
3. Generate platform outputs. A tool like Style Dictionary turns one JSON file into TypeScript constants, iOS resource files, Android XML, and CSS variables. That is the "single source of truth" rendered in three places.
4. Wire it into your React Native build. Add a script to regenerate the tokens on every build, import the typed constants, and replace raw values across the codebase. A simple lint rule (no hex literals, no raw padding: 13) catches the leftovers.
5. Mirror the tokens in Figma. Use Figma Variables or a plugin like Tokens Studio to keep the design file in sync with the JSON, so designers and engineers are editing the same dataset.

The order matters: tokens before screen polish, not after. That is the discipline Dolfy's Design Foundation step enforces for greenfield projects, and it is the discipline any existing React Native project can adopt without rewriting its screens.

FAQ

What is a design token vs a design variable?

A design variable is the storage mechanism in a design tool (a Figma Variable, a CSS custom property, a SCSS variable). A design token is the concept — a named design decision with a value, a type, and a description that can travel across tools and platforms. Every token can be stored as a variable, but a variable on its own is just a label.

Do design tokens work with Tailwind CSS in React Native?

Yes. Tools like Style Dictionary can generate a Tailwind config from a token JSON, and libraries like NativeWind let you use Tailwind utilities in React Native with full token-driven theming. That is why the combination of design tokens, Tailwind, and TypeScript types is the standard mobile stack for teams that want consistency without giving up the speed of utility-first CSS.

How are design tokens different from a theme file?

A theme file is one consumer of tokens. Tokens are the source; a theme is an output. If you change the brand blue in a theme file, only the code that imports that theme updates. If you change it in the token source, Figma, the Tailwind config, the TypeScript constants, the web build, and the native builds all update together.

When should a small team invest in design tokens?

Before the second screen. The honest threshold is "as soon as you have more than one engineer or one designer touching the same product." Tokens are cheap to set up early and expensive to retrofit late, and a small team that adopts them on day one avoids a multi-week refactor in month six.

Where do design tokens fit in the future of mobile app design?

They fit at the centre, which is the only place they can be if AI app design tools are going to be useful at all.

The next generation of mobile products is going to be built by small teams and AI agents working together, which means the system has to be machine-readable end to end. Tools that generate screens without a token foundation will keep producing inconsistent output, and tools that generate tokens alongside screens will be the ones that survive contact with real engineering. That is also the direction Dolfy.ai is built around: a 5-step Design OS, a Design Foundation step that defines tokens before screen work, specialised AI agents for product and architecture decisions, and an export path that hands you production-ready React Native + Tailwind + TypeScript with the same token system the design was generated from.

If you want a workflow that treats your design decisions as one source of truth from Figma to the App Store, explore Dolfy and see how a token-first, AI-guided design process changes the quality of the work — and the speed at which you can change it.