Cross-Platform Design Tokens — Getting Web + Mobile to Feel Like One Product

Most full-stack SaaS templates ship a Next.js web app and a React Native mobile app in the same repo. Fewer share design tokens between them. And that's the difference between an app that feels like one product on two surfaces and an app that feels like two companies wearing the same t-shirt.

The visual drift problem

Open a random full-stack SaaS template. Compare the primary button color on the web dashboard to the primary button color on the mobile app. Are they exactly the same? Same shade, same weight, same radius, same padding? In most templates, no — they're close but not identical, because the web team picked one hex and the mobile team picked another, and there's no shared source of truth.

That drift compounds. Six months later, the web app has ten shades of blue, the mobile app has eight, and neither team can tell you which is the "brand" blue.

What shared tokens actually mean

Shared design tokens for a full-stack SaaS means one JSON (or TypeScript) file that defines every visual value the app uses, and both the web app and the mobile app import from it.

tokens/
colors.ts // brand, surface, text, border, semantic (success/warning/error)
typography.ts // heading scale, body scale, mono
spacing.ts // 4px base unit, exposed as space.1, space.2, space.4, space.8
radius.ts // sm, md, lg, full
shadow.ts // sm, md, lg

The web app consumes them via Tailwind config or a CSS-in-JS theme. The mobile app consumes them via a theme provider that resolves platform-appropriate values. Same source, different runtimes.

Where web and mobile should diverge

Sharing tokens does not mean web and mobile should look identical. There are good reasons to diverge:

• Typography: iOS has SF Pro, Android has Roboto (or Noto), the web can have anything. Shared tokens define the scale (heading.xl = 32px); platform code picks the family.
• Touch targets: mobile needs a 44pt minimum tap target, web can be smaller. Shared spacing tokens, different application.
• Elevation: mobile uses subtle shadows or none (Material) plus platform blur effects; web can use heavier shadows because there's more visual noise to compete with.
• Corner radius: iOS trends smaller (8-12px), Android trends larger (16-24px), web is a taste call.

A well-designed shared tokens system exposes the primitives (color, spacing, scale) and lets the platform layer pick the composition. Templates that force pixel-identical layouts across web and mobile end up making both surfaces feel wrong.

Auditing a template's design layer

• Search the codebase for hex codes. If there are more than ~20 outside the tokens file, the template has drifted.
• Look at the tokens file. Is it semantic (text.subtle) or raw (gray800)? Semantic wins for theming.
• Check dark mode. Is it token-based (each token has a light + dark value, resolved at the provider) or if (isDark) scattered through screens? The former scales, the latter doesn't.
• Check for a component gallery (Storybook, or a /design route). Templates that shipped one thought about design as a system, not screens.
• Check for component variant definitions in the theme, not the component. Button.variants.primary in theme > with hardcoded styles.

The handoff pattern that scales

[7:02 AM]The design handoff pattern that works long-term for full-stack SaaS templates:

1. Designer works in Figma with a token library that mirrors the code tokens.
2. When tokens change (a new brand color, an updated radius scale), the designer edits Figma and files a PR against the tokens file with the same names.
3. Engineering merges the PR, tokens flow to both web and mobile instantly, no screen touched.
4. Component names in Figma match component names in code — PrimaryButton in both places.

Templates that ship this pattern from day one save the design team weeks of translation work per project. Templates that don't force every design change to become an engineering task.

Applighter's approach

At Applighter, the cross-platform tokens layer is treated as first-class — one tokens file consumed by both the Next.js web app and the Expo mobile app, semantic naming throughout, platform-appropriate composition at the render layer, Figma library that mirrors code component names. Not because we're perfect on this — because we watched too many full-stack templates ship with a drift problem baked in.

Whatever template you evaluate, ask this one question: is there a single tokens file that both surfaces import? If yes, the design work will scale. If no, budget the retrofit.