Custom Design Systems for React Native: A Builder's Guide

Every mobile app that scales eventually hits the same wall: screens that almost match. The buttons on checkout are a slightly different blue than the buttons in settings. One card has 12px of padding, another has 14, and nobody remembers why. A dark mode shipped three releases ago still leaves two forms unreadable. The problem is never a single mistake — it's drift. And drift is what happens when design decisions live in individual screens instead of in a system.

If you're building a mobile app with AI, the stakes are higher. A model generating one screen at a time doesn't remember what it picked yesterday — unless the system itself remembers for it. A custom design system for React Native is how you make the system remember.

This guide walks through how to build a custom design system inside a RapidNative project — one that keeps every screen on-brand, flips to dark mode cleanly, and stays coherent as the AI generates the next ten screens. Underneath it's React Native + Expo + NativeWind (that's what RapidNative emits), but the workflow applies to anyone trying to turn a brand into a shippable mobile experience.

What a design system actually is (in code, not slides)

A design system is often described as "a shared language for designers and developers." That's true but useless when you have a blank project and a deadline. In code, a design system is three concrete layers:

1. Primitives — the atomic values. Hex codes, pixel measurements, font names. #0A84FF, 16px, Inter.
2. Tokens — semantic aliases on top of primitives. primary, background, foreground, border, destructive. Tokens never contain raw values — they point at primitives.
3. Components — the UI pieces that consume tokens. A Button uses primary for its fill, not #0A84FF directly. A Card uses card and card-foreground, never a raw gray.

The whole point of this stack is that a one-line change at the token layer propagates everywhere. Rebrand to a new primary blue? Change one line in theme.ts. Every button, badge, and link follows automatically. Hardcode #0A84FF into 42 screens, and your rebrand becomes a 42-screen refactor.

RapidNative's generated projects ship with this architecture out of the box, following the same CSS-variable pattern NativeWind recommends for theming. The question is how to make it yours.

Step 1: Seed the system from your brand

A RapidNative project starts from one of five inputs: a prompt, a sketch on a whiteboard, a screenshot, a PRD, or — most interesting for design-system work — a reference website. When you point the AI at an existing brand's web presence, it extracts the color palette, typography cues, and often the logo asset into the project's theme.ts file before a single screen is drawn.

The practical workflow:

• Give the AI your marketing site URL ("build a mobile app for stripe.com, same brand").
• The agent fetches the page, parses the stylesheet, pulls primary / secondary / accent colors (preferring explicit CSS variables when present), and seeds the design tokens.
• Font families are mapped from the site's typography stack onto Expo-friendly equivalents.
• Any obvious logo asset gets downloaded and placed in the project.

The output isn't a copy of your website. It's a starting token set — a theme file where the primary, background, and foreground colors already match your brand before a single screen gets drawn.

This matters because the alternative is handing a model a vague color brief ("make it blue, kind of like Stripe") and getting a different blue each screen. By anchoring the token layer first, every subsequent generation inherits the same palette.

Step 2: Understand the theme file you were handed

Open any fresh RapidNative project and you'll find a theme.ts under the mobile source tree. Abbreviated, it looks like this:

export const lightTheme = vars({
  '--background': '255 255 255',
  '--foreground': '10 10 10',
  '--primary': '10 132 255',
  '--primary-foreground': '255 255 255',
  '--secondary': '240 240 240',
  '--muted': '245 245 245',
  '--border': '229 229 231',
  '--destructive': '239 68 68',
  // chart colors, sidebar colors, etc.
});

export const darkTheme = vars({
  '--background': '10 10 10',
  '--foreground': '245 245 245',
  '--primary': '10 132 255',
  '--primary-foreground': '255 255 255',
  // mirrors lightTheme with dark-appropriate values
});

Two things to note:

• Colors are stored as space-separated RGB triples, not hex. That lets Tailwind compose them with alpha channels (bg-primary/50 works out of the box). It's the same syntax Tailwind's color system documents for CSS-variable theming.
• Every token has a -foreground counterpart. Whenever you place foo on a surface, use foo-foreground for the text that sits on it. This single rule prevents 90% of accessibility complaints.

A tailwind.config.js sits beside this file and wires the CSS variables into Tailwind's color system:

colors: {
  background: 'rgb(var(--background) / <alpha-value>)',
  foreground: 'rgb(var(--foreground) / <alpha-value>)',
  primary: {
    DEFAULT: 'rgb(var(--primary) / <alpha-value>)',
    foreground: 'rgb(var(--primary-foreground) / <alpha-value>)',
  },
  // ...
}

Now any screen can write className="bg-background text-foreground" or className="bg-primary text-primary-foreground" and get the right colors in both light and dark mode automatically. That <alpha-value> placeholder is why Tailwind utilities like bg-primary/20 and border-border/40 work without you touching the token file.

Step 3: Semantic classes are the real enforcement mechanism

Here's where most design systems quietly fail: the system exists, but nobody uses it. A developer in a hurry writes backgroundColor: '#0A84FF' on a one-off view. Six months later the brand changes and that view is now wrong.

RapidNative's agent is prompted to never hardcode colors. It writes bg-primary instead of bg-blue-500, and text-foreground instead of color: '#111'. The prompt enforces this at generation time, so every screen the AI emits is already drift-resistant. (For a deeper look at how the agent compiles natural-language style requests into NativeWind class strings, see our post on how RapidNative compiles natural language into NativeWind.)

The practical upshot: when you later decide your primary blue needs to be a shade darker, you change one RGB triple in theme.ts, and every screen updates on the next preview render. No search-and-replace. No missed screens.

For your own hand-edits, follow the same rule. Any time you reach for a hex code, stop and ask whether a token already covers it. Nine times out of ten, one does — you just needed to use muted, border, or accent instead.

Step 4: Dark mode — the gotcha most teams miss

Dark mode in React Native looks deceptively simple: swap one vars() object for another at the root and let CSS variables cascade. RapidNative's themed scaffold wires this with a small ThemeProvider mounted in app/_layout.tsx. Inside the provider, React Native's useColorScheme() hook returns either 'light' or 'dark', and the provider applies the matching vars() object to a wrapper view.

The subtle bug — and this trips up almost every team the first time — is that React Native Modal components portal outside your root view. If the theme variables only live on a wrapper <View>, your modals render against an unthemed root and look wrong in dark mode. Any transparent background becomes an unreadable white rectangle.

The scaffold's provider works around this by also setting the CSS variables on document.documentElement (for web) and on the root view's style directly (for native). Said differently: when you adapt the theme provider, keep the dual-write. Don't trust that wrapping your tree is enough.

If you want to go deeper on how RapidNative generates theme-aware code, we've written about our theme-aware React Native architecture separately.

Step 5: Point-and-edit as a design-system refinement tool

Once your project is running, the fastest way to iterate the design system is not to open theme.ts by hand — it's to use RapidNative's point-and-edit feature. Click a button, type "make the primary color a warmer orange," and the AI updates the token in the right place. Every screen that uses bg-primary moves with it.

What makes this different from "ask the AI to recolor this button" is that the AI knows the hierarchy. If you ask for a token-level change, it edits the token. If you ask for a one-off tweak ("make this button red"), it adds a semantic variant like destructive or a locally overridden class. The system layer stays clean.

Common refinements that work well this way:

• "Soften all card shadows by 30%."
• "Increase the base border radius from 8px to 12px."
• "Make muted text darker in light mode."
• "Add a 'success' token in green matching our brand palette."

Each of these produces a one-file edit at the token layer, not a sweep across screens.

Step 6: Typography scale — the second half of the system

Colors are only half of a design system. The other half is type. The scaffold defines three semantic font families:

• font-heading — for H1, H2, headlines
• font-body — for paragraphs, buttons, labels
• font-mono — for code, numeric readouts, timers

Behind these, Expo loads the actual font files (Inter and JetBrains Mono by default), and tailwind.config.js maps the semantic names onto them. Swap Inter for your brand font once, and every heading in the app follows.

Size, line-height, and letter-spacing come from Tailwind's default scale (text-sm, text-base, text-lg, text-xl, tracking-tight, etc.). You rarely need to extend this — the default scale is well-tested and reads correctly on mobile. If your brand demands a custom type ramp, override only the sizes that drift from the default, so you still inherit Tailwind's good defaults for the rest.

Step 7: Component variants and state

A real design system doesn't stop at "a button." It defines what the button looks like when it's hovered, pressed, disabled, loading, destructive, or ghost. In RapidNative's generated code, these variants compile down to NativeWind class strings:

<Pressable
  className="bg-primary text-primary-foreground active:bg-primary/90 disabled:opacity-50"
>

Three things worth noticing:

1. The pressed state uses the same primary token at a lower opacity — not a hand-picked darker color. The token still owns the hue; the modifier owns the interaction.
2. Disabled state is purely opacity-driven, which means it adapts to light and dark mode automatically.
3. Destructive buttons swap primary for destructive — same component, same shape, just a different token binding.

When you ask the AI for a new component ("I need a tag chip with four variants"), it will follow this pattern by default: tokens for color, modifiers for state, structural styles for shape. This is also how libraries like Tamagui and Gluestack approach variants, but you get the pattern as emitted code rather than a dependency you ship.

Step 8: Responsive breakpoints and spacing scale

Phones vary. A design that fits on a small iPhone SE breaks on a Pro Max unless the system is deliberate about it. NativeWind supports Tailwind's breakpoint syntax (sm:, md:, lg:), and RapidNative-generated code uses it where screens have multi-column layouts or tablet variants. A card grid can read as className="grid-cols-1 sm:grid-cols-2 md:grid-cols-3" and the layout will reflow sensibly.

For spacing, the scaffold leans on Tailwind's default rhythm (p-2, p-4, p-6, gap-4, space-y-6). This isn't glamorous, but it's the single highest-leverage design decision you can make: pick a consistent 4px or 8px grid and never deviate. Humans don't consciously notice "all my paddings are multiples of 4," but their eyes do, and the result reads as polished rather than ad hoc.

The same scale shows up for border radius (rounded-md, rounded-xl), shadows (shadow-sm, shadow-lg), and opacity (opacity-50, opacity-70). Each of these ladders maps to a token, and each token is one line to adjust.

Step 9: Reusing the system across projects

If you're an agency or a founder running multiple products, you don't want to redesign the token set every time. Two approaches work inside RapidNative:

• Clone a seeded project as a starting point. Point the AI at your previous project, say "use the same theme," and it will carry the theme.ts into the new project before generating screens.
• Lock the system in via a reference URL. If you have a living design-system site (even a one-page Figma export published to a URL), feed that URL to the AI. The token-extraction pipeline will reconstruct your palette and typography on every new project.

Teams on the Team plan can share projects, which means a single design-system project can act as the canonical source — every new product scaffold starts from that project's theme file. This is the pattern agencies on RapidNative use to run white-label delivery at scale: a single tokenized shell, many branded apps.

Common pitfalls (and how the system prevents them)

Three patterns kill design systems in practice. The architecture above sidesteps each:

• Hex codes in screens. Prevented by the agent's "never hardcode colors" prompt and by code review on your own commits. If you spot a hex, replace it with a token.
• One-off font sizes. Prevented by sticking to Tailwind's scale (text-sm, text-base, text-lg). Custom sizes should land in the config, not inline.
• Divergent dark-mode treatments. Prevented by using -foreground counterparts for every surface, and by trusting the token swap rather than writing isDark ? '#eee' : '#333' conditionals.

People also ask

Can I use my existing React Native design system (like Tamagui or Gluestack) inside RapidNative?

Not directly today. RapidNative-generated code targets Expo + NativeWind as its styling baseline because that's what the AI's code generation has been trained and tested against. You can port components manually after export, but during generation the agent stays within the NativeWind ecosystem.

How do I keep the design system consistent when the AI generates many screens?

The system itself does the enforcement — not the AI's memory. Because every screen references semantic tokens (bg-background, text-foreground, bg-primary), screens stay in sync automatically. The AI is prompted never to hardcode colors, so there's nothing to drift. Changing a token in theme.ts updates every screen on the next render.

Does RapidNative support multiple themes beyond light and dark?

The architecture does. The vars() system can hold any number of named theme objects, and you can switch between them via a provider. The scaffold ships with light and dark, but adding a "high contrast" or seasonal theme is a matter of defining another vars() block and extending the provider.

Can I export the design system and use it outside the app?

Yes. Every RapidNative project exports as a full React Native + Expo codebase. The theme.ts and tailwind.config.js are standard files — you can lift them into any other NativeWind project, or translate the tokens into CSS variables, Figma variables, or Style Dictionary configs for cross-platform consumption.

Why this approach beats templates

Mobile templates ship with a fixed look. You pay for a food-delivery template and get the food-delivery template's colors, type, and components whether or not they match your brand. The design system is a given, and bending it to your brand is a line-by-line fight.

Generated code is different because the system is parameterized by your brand from the start. The AI isn't painting your brand onto a template — it's generating screens that read from a token file you control. Rebranding is a single-file change. Introducing a new product with the same identity is a project clone. Shipping dark mode is already done.

That's the full stack of a custom design system for React Native working the way it's supposed to: one source of truth, cascading through every component, under the control of the person who owns the brand — not the person who wrote the last screen.

Ready to see what a brand-coherent app looks like from a prompt? Start building free on RapidNative — 20 credits, no card. Point it at your brand site and watch the token file write itself. If you're deciding which plan fits, our pricing page breaks down what's included at each tier.