DEV Community: Sophie F A

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

Sophie F A — Thu, 06 Aug 2026 09:13:40 +0000

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:

Designer works in Figma with a token library that mirrors the code tokens.
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.
Engineering merges the PR, tokens flow to both web and mobile instantly, no screen touched.
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.

React Native i18n in 2026: A Practical Expo Router Playbook

Sophie F A — Mon, 03 Aug 2026 07:35:54 +0000

If your React Native app only speaks English, you're leaving ~75% of smartphone users on the table. Here's the modern stack for shipping a multilingual Expo app without three days of glue code.

The Stack

react-i18next: translation management (6M+ weekly downloads, TS-first)
expo-localization: device locale detection (or react-native-localize for bare RN)
Intl: dates, numbers, currencies (built into Hermes)
I18nManager: RTL layout flipping

Setup in 4 Steps

1. Install

npx expo install expo-localization
npm i i18next react-i18next

2. Translation files

locales/
  en.json
  es.json
  ar.json

{
  "welcome": "Welcome",
  "cart": {
    "itemCount_one": "{{count}} item",
    "itemCount_other": "{{count}} items"
  }
}

Use the ICU plural suffixes (_one, _other, _few, _many, _zero). Arabic has 6 plural forms, so get this right on day one.

3. Bootstrap

// i18n.ts
import i18n from 'i18next';
import { initReactI18next } from 'react-i18next';
import * as Localization from 'expo-localization';
import en from './locales/en.json';
import es from './locales/es.json';
import ar from './locales/ar.json';

const deviceLocale = Localization.getLocales()[0]?.languageCode ?? 'en';

i18n.use(initReactI18next).init({
  compatibilityJSON: 'v4',
  resources: {
    en: { translation: en },
    es: { translation: es },
    ar: { translation: ar },
  },
  lng: deviceLocale,
  fallbackLng: 'en',
  interpolation: { escapeValue: false },
});

export default i18n;

Two production-important bits: compatibilityJSON: 'v4' for modern plural rules, and escapeValue: false because RN already escapes JSX.

4. Wire into Expo Router

// app/_layout.tsx
import { Stack } from 'expo-router';
import './i18n';

export default function RootLayout() {
  return <Stack />;
}

Then in any component:

import { useTranslation } from 'react-i18next';

const { t } = useTranslation();
<Text>{t('cart.itemCount', { count: 3 })}</Text>
// "3 items"

The Gotchas Nobody Warns You About

Never concatenate around t(). Word order changes across languages:

// ❌ Breaks in Japanese, German, Arabic
<Text>{t('hello')} {user.name}!</Text>

// ✅ Whole sentence is one key
<Text>{t('greeting', { name: user.name })}</Text>

RTL doesn't flip everything. Flexbox auto-flips, but you'll need to fix:

left/right → use start/end
Directional icons → wrap in transform: [{ scaleX: -1 }] when I18nManager.isRTL
Hardcoded textAlign

Hardcoded strings in third-party UI kits. Buttons in libraries like RN Elements ship English defaults. Override or pick i18n-aware libs.

Push notifications aren't localized by the phone: your backend has to send the localized copy or use OS-level notification categories.

Formatting

Never string-concat dates or currencies. Use Intl:

new Intl.DateTimeFormat(i18n.language, { dateStyle: 'medium' }).format(new Date());
new Intl.NumberFormat(i18n.language, { style: 'currency', currency: 'USD' }).format(29.99);

Add @formatjs/intl-datetimeformat polyfills if you need older Android or less common locales.

Testing Discipline

Turn on saveMissing in dev. react-i18next logs every missing key. Fail CI on any.
Pseudo-localize with en-XA. This surfaces hardcoded strings and 30–40% longer text for layout stress-tests.
Snapshot per locale. French/German/Arabic snapshots catch layout regressions.

Shortcut

If you're starting fresh, RapidNative generates the whole i18n scaffold (provider, layout wiring, translation files, RTL flags) from a natural-language prompt. You get the same setup you'd write by hand, in about 30 seconds.

Otherwise: ship it. It's 2–3 days of setup and it opens up 3 billion more users.

How to Build a Video Calling App with React Native and WebRTC

Sophie F A — Wed, 15 Jul 2026 07:22:22 +0000

The WebRTC pipeline is where the interesting engineering lives. The UI around it — call setup screen, contact list, in-call controls, history log — is boilerplate you've built a hundred times. That's exactly the layer that RapidNative handles well: describe the screens you need, get production-ready React Native + Expo code you can drop straight into your Metro bundle.

For a video calling app, that's the pre-call lobby ("Start Call" / "Join Call" / recent contacts), the in-call overlay (avatar, timer, mute/video/end buttons, participant list for group calls), and the post-call summary. You can start from a PRD or sketch the flow and get a working Expo project in minutes, then wire in the react-native-webrtc layer described above.

The pattern generalizes: use AI to move fast on UI-heavy layers where you're implementing patterns everyone recognizes, and spend your engineering time on the parts that are genuinely hard — like the ICE candidate gathering that just failed on your test call. If you're building anything real-time, our writeups on how RapidNative delivers real-time React Native previews and how we built real-time collaboration for team app building cover the WebSocket patterns that pair nicely with WebRTC signaling.

Frequently Asked Questions

Does react-native-webrtc work with Expo Go?

No. react-native-webrtc ships native iOS and Android modules that Expo Go cannot load. You need to move to Expo Dev Client or the bare workflow and use EAS Build (or a local expo run:ios/expo run:android) to include the native code. The @config-plugins/react-native-webrtc plugin handles the required permissions automatically.

How much does a WebRTC video calling app cost to run?

For 1-to-1 calls, near zero — media flows peer-to-peer. Your only costs are the signaling server (a $5/month VPS handles thousands of concurrent calls) and TURN relay for the roughly 15–20% of calls that fall back to relayed mode. Budget $0.40 per GB of TURN traffic. Group calls with an SFU move more media through your servers and cost proportionally more.

Can I use WebRTC for one-to-many streaming?

WebRTC is optimized for two-way conversation. For one-to-many broadcast (like a webinar or Twitch-style stream), you can use an SFU, but at scale you'll pay more than a protocol like HLS or LL-HLS designed for that pattern. WebRTC shines when latency matters more than viewer count.

What's the difference between STUN and TURN?

STUN helps a peer discover its own public IP address so two peers behind NAT can attempt a direct connection. TURN is a fallback: when direct P2P fails (usually because both peers are behind symmetric NAT), TURN acts as a media relay. STUN is cheap and free servers exist; TURN uses your bandwidth and typically costs money.

Is WebRTC secure?

Yes. All WebRTC media is encrypted with DTLS-SRTP by default — it's not optional in the spec. You cannot send unencrypted media. The signaling channel is your responsibility; use WSS (secure WebSockets) or HTTPS for whatever you build.

Wrapping Up

You now have every piece needed for a production-quality react native video calling app: a signaling server, a peer connection lifecycle, media capture, offer/answer exchange, ICE handling, and the standard call controls. Add a TURN server, wire the UI to your app's state management, and you're 80% of the way to shipping.

The hardest part of WebRTC isn't the API — it's the network. Test on real cellular connections, log ICE state transitions, and instrument connection failures early. Everything else is UI polish, and that's the part AI is happiest to write for you.

Ready to build? Start with RapidNative to spin up the app shell around your WebRTC layer in minutes, or browse more React Native tutorials on the blog.