90 Day Plan to Build a Mobile Design System for App Teams

A mobile design system is the combined set of design tokens, a component library, documented patterns and a governance process that keeps an app's interface consistent as it scales across teams and releases. The main payoff is speed with fewer regressions: teams ship faster because they stop rebuilding the same button, spacing rule or empty state from scratch. The first practical move is a token and component inventory: audit every screen, list every colour, spacing value and control in use, then flag the duplicates before writing a single line of new code.

TL;DR:

A mobile design system maintains consistency across platforms by using layered tokens, a component library, and detailed documentation to prevent drift and regressions.

Platform-specific conventions for touch targets, navigation, and offline states are essential, as mobile interactions diverge significantly from web design standards.

Building and enforcing governance processes, including approval workflows and metrics tracking, are crucial to prevent system decay as teams expand or change.

Automated token pipelines and native mapping strategies enable rapid updates and parity between iOS and Android without compromising native user experience.

Starting with a thorough inventory and incremental rollout, including pilot testing and clear deprecation policies, ensures sustainable and reliable system adoption.

What a mobile design system actually contains
Why mobile needs its own design system, not a shrunk-down web one
The core ingredients every mobile system needs
Governance and the operating model that stops drift
Implementation patterns: token pipelines, parity and tooling
Examples worth studying before you build your own
A 90-day plan to start or audit your system
Pocket App's experience building for real teams
Three lessons from building mobile systems, and one contrarian take
Where to go deeper
Sources
FAQ

What a mobile design system actually contains

A UI kit is a set of static screens. A style guide is a document with colours and fonts pasted into it. A mobile design system is neither. It's a living, versioned product with four interdependent parts: tokens, components, patterns and documentation, all maintained together so a change in one propagates correctly through the rest.

Tokens carry the visual decisions as data rather than hard-coded values. Primitive tokens are the raw palette (blue.500, space.4), while semantic tokens give those primitives a job (color.action.primary, spacing.card.padding). Semantic tokens are what components actually reference, which means a rebranding touches one file, not four hundred screens.

The full inventory usually breaks down as:

Design tokens: colour, spacing, type scale, radii, elevation and motion timing.
Component library: buttons, inputs, navigation bars, cards, tuned specifically for touch.
Pattern library: reusable flows such as onboarding, search and error states.
Living documentation: usage rules, code samples and accessibility notes, typically in Figma for design and Storybook (or an equivalent) for engineering.

Skip the documentation and the rest decays fast. A component nobody understands gets copied wrong, and the drift starts within a sprint or two.

Why mobile needs its own design system, not a shrunk-down web one

Mobile interaction is fundamentally different, and treating it as a smaller web viewport is where most systems fail. There's no hover state on a phone. Every interactive element has to work as a deliberate tap, swipe or long press, on a screen the user is often holding with one hand while walking, queuing, or half-watching something else.

That changes the design constraints in ways a desktop system never has to solve for:

Touch targets: Ramotion's research on mobile-specific design patterns confirms tap sizing, gesture handling and offline states behave materially differently from web equivalents, and treating them as an afterthought produces measurably worse usability.
Connectivity: patterns need built-in offline and low-signal states, not just a loading spinner that never resolves.
Platform convention: Apple's Human Interface Guidelines and Google's Material Design diverge on navigation, gestures and typography. A mobile design system has to decide, component by component, when to follow platform convention and when brand consistency wins out.
Release cadence: app store review cycles mean a broken component can't be hotfixes the way a web bug can. Governance and testing have to account for that lag, something covered in more detail in our guide to app lifecycle management.

Get the platform conventions wrong and users notice immediately, because a Material-style back gesture on iOS feels foreign in a way a slightly off shade of blue never will. Our iOS app design guide goes deeper on where Apple's conventions should override brand preference.

The core ingredients every mobile system needs

This is the actual inventory, in the order most teams should build it.

Token architecture: structure tokens in three layers, primitives, semantic tokens, and platform tokens, so raw values map to role-based aliases and then to native iOS and Android formats. This layered approach, aligned with the W3C Design Tokens Community Group's emerging format standard, means a designer changes color.action.primary once and both platforms update through a build transform rather than a manual edit.
Primitives and atomic components: the smallest reusable pieces, tuned for touch rather than pointer input, spanning layout containers, input controls, navigation elements and media wrappers. Button padding, input height and icon sizing all need mobile-specific minimums here, not values inherited from a web kit.
Pattern library: composite flows that solve a real mobile problem, onboarding sequences, search-with-filters, multistep forms, and offline or error states. Patterns document not just how a screen looks, but the decision logic behind it: what happens when a form submission fails on a flaky connection, for instance.
Documentation depth: every component needs do's and don'ts, an accessibility note (minimum contrast, screen reader labelling, touch target size), and, critically, a migration or deprecation guide so nobody keeps building on a component that's about to disappear.

Pro Tip: Write the deprecation note before you ship the replacement component, not after. Teams that document "why this is going away and what to use instead" at launch see far fewer stragglers still using the old version six months later.

Mobile implementations increasingly follow the pattern of mapping brand tokens straight to native platform values, a structure that design systems practitioners have documented as the most reliable way to keep platform look-and-feel intact while still guaranteeing parity between iOS and Android builds. That's the difference between a system that merely looks consistent in Figma and one that actually ships consistent behaviour to two different operating systems with two different design philosophies.

Governance and the operating model that stops drift

A design system without governance decays the moment the second team starts contributing. Design system governance defines who can change what, how decisions get made, and how success gets measured, and without it, components fork silently until nobody trusts the source of truth any more.

Three governance models dominate in practice:

Centralised: one dedicated team owns every component and decision. Fastest to keep consistent, slowest to scale across many product squads.
Federated: a core team owns the foundation while contributors submit components through a defined review process. This tends to be the most durable model for mid-size to large mobile teams.
Open/community: anyone can contribute with light oversight. It sounds appealing, but Designsystems found that community-only systems without dedicated staffing tend to be neglected within two years, because nobody owns the unglamorous maintenance work.

Centralised and federated models are widely regarded as the two sustainable options, largely because both assign clear ownership rather than assuming goodwill will hold a system together indefinitely.

The workflow itself, as Brad Frost's governance framework lays out, should run through proposal (an RFC), prototype, review, build, test and a staged release, with a visible deprecation policy attached to every retired component so teams aren't caught out.

None of that matters without measurement. Fragments' governance framework recommends tracking component adoption rate, token coverage across the codebase, exception volume (how often teams break pattern), and time to resolve drift once it's spotted. Deprecated-pattern usage is a particularly good leading indicator: if an old button variant is still showing up in new pull requests three months after its replacement shipped, governance has already broken down somewhere upstream.

Implementation patterns: token pipelines, parity and tooling

The technical backbone of any mobile design system is the pipeline that turns a design decision into shipped code without a manual handoff at every step.

A typical token pipeline runs: Figma variables (where designers set the values) → an exported JSON format → a transform step that generates platform-specific token files for iOS (Swift or .xcassets) and Android (XML or Kotlin). Tools like Style Dictionary handle that transform layer, so one source of truth produces two platform-native outputs automatically.

For platform parity, three strategies work in practice:

Platform mirrors: build near-identical component pairs for iOS and Android, styled to match each platform's own conventions rather than forcing pixel parity.
Semantic tokens as the parity layer: keep the semantic layer identical across platforms and let the platform-specific token values handle the visual differences.
Best-fit native mapping: for complex components (date pickers, native share sheets), map to the platform's built-in control rather than rebuilding it, since users already know how the native version behaves.

On tooling, Storybook (or a mobile-focused equivalent) gives engineers an interactive component gallery that mirrors what designers see in Figma. Pair it with automated visual regression testing and CI linting that blocks a pull request if a component uses a raw hex value instead of a token, and drift gets caught before it merges rather than after a user reports it.

Testing has to go beyond a design review. Run accessibility audits against WCAG contrast and touch-target guidance, stress-test components on lower-spec devices where animation and load times behave differently, and pilot new components in a real feature branch inside the app before a full rollout, rather than trusting a Figma prototype alone. For teams weighing React Native or Flutter against native builds, our multi-platform development tools guide covers how token pipelines adapt to each framework.

Examples worth studying before you build your own

Rather than starting from a blank file, inspect a few production systems and community kits to see how the pieces above actually fit together.

Native-UI: a production-grade React Native design system that publishes tokens, primitives and platform-aware components together, useful as a reference for how a real token-to-component structure is organised in code rather than in theory.
Appetite UI: an example of a token-driven Figma kit for mobile apps, useful for seeing how a single source of truth in Figma variables can drive rapid re-theming across dozens of screens without manual rework.
What to check in any example: does it show token mapping to both platforms, not just one? Does it include accessibility annotations on components, not just visuals? Is there any evidence of CI integration or automated checks, or is it a static file that will drift the moment someone opens it?

Starter kits are useful for prototyping speed, but treat them as a skeleton. The governance and documentation layer is what turns a downloaded kit into an actual system your team can trust in six months.

A 90-day plan to start or audit your system

Days 0 to 14: inventory every screen and every token in current use, flag inconsistent spacing or colour values, and fix the cheapest accessibility wins (contrast ratios, missing labels) immediately. Success looks like a spreadsheet with every duplicate value named.
Days 15 to 45: ship the first set of core tokens and five to ten sample components with working code examples for developers, not just Figma mockups. Success is a Storybook or equivalent gallery that engineers can actually import from.
Days 45 to 90: put governance in place, an RFC process, a review owner, CI checks that catch raw values, and pilot the system in one real feature before wider rollout. Success is measured adoption, not just a launch announcement.

Pro Tip: Don't wait for the "perfect" token set before piloting. A rough token layer running in one real feature teaches you more about gaps than three more weeks of Figma refinement.

For teams starting from wireframes rather than an existing app, our step-by-step wireframing guide pairs well with the inventory stage above.

Pocket App's experience building for real teams

Pocket App has delivered over 300 mobile projects for organisations including WWF, Dechra and Crocus, spanning charity, healthcare and retail. That range means recurring exposure to the same problem: teams need consistent, well-governed mobile interfaces that hold up across releases, not a one-off screen set that decays after launch.

Three lessons from building mobile systems, and one contrarian take

Three things hold up across most mobile builds: tokens without governance drift within months; documentation gets skipped first and costs the most later; and teams underestimate how differently iOS and Android users actually behave. My contrarian take: chase pragmatic platform parity over exact visual matching. A button that feels native on each platform beats one that looks identical on both. Run your token audit this week.

— Paul

Where to go deeper

For governance frameworks, read Brad Frost's governance process and Fragments' metrics framework. For token standards, see the DTCG-aligned token article and inspect Native-UI's repository for a working code example.

If you'd rather have an experienced team build or audit the system with you, Pocket App's mobile app development service covers everything from the initial token audit through to shipped, governed components across iOS and Android. We've also worked alongside partner teams featured in TrackAff's mobile app portfolio on comparable delivery workflows, and we're happy to talk through where your current setup stands before you commit to a rebuild.

Sources

FAQ

What is a mobile design system?

It's the combined set of design tokens, a mobile-specific component library, documented usage patterns and a governance process that keeps an app's interface consistent across teams and releases.

How is a design system different from a UI kit?

A UI kit is a static set of screens or components; a design system adds tokens, governance, versioning and living documentation that keep those components consistent as the product changes.

Should I use the same design system for iOS and Android?

Use the same semantic tokens and component structure across both, but let platform-specific tokens and native conventions (from Apple's HIG and Google's Material Design) handle the visual differences.

How do design tokens map to native code?

Tokens are usually set in Figma variables, exported as JSON, then run through a transform tool that generates platform-native formats for iOS and Android, so one source of truth produces two outputs.

Which governance model works best for a small team?

A centralised model, where one team owns every component and decision, is usually more sustainable for a small team than an open contribution model, which tends to be neglected within two years without dedicated staffing.