In a design system with web and native mobile apps, what do native apps share with the web component library, and what do they rebuild?
answer
- code stops at the platform line
- the contract crosses, the code does not
- one token source, many outputs
- anatomy, states, behaviour, accessibility intent
- native rendering and platform settings
basics
~20 sNative apps share the design tokens, the component specs (anatomy, variants, states, behaviour, accessibility intent) and the naming, not the web code. Each platform rebuilds the components with its own UI toolkit, input model and accessibility services.
solid answer
~40 sA web component library is code that renders web markup, so a native mobile app cannot turn it into native controls. What crosses the platform line is the **design contract**: design tokens (color, type, spacing, radius, motion) exported from one source into each platform's format, and the per-component spec — anatomy, variants, states, behaviour and the accessibility contract (role, accessible name, what is announced, focus order). Each native team builds the component in its own UI toolkit against that spec, using native controls, gestures, the platform's text-size and reduced-motion settings, and the platform's screen reader. Shared component and variant names keep designers and every codebase talking about the same thing, and documented platform deviations cover the places where the platform's own convention should win.
go deeper
Recall the split: tokens, specs and names are shared; component code is rebuilt on each platform. Be able to say why web code cannot become native controls.
Explain what a spec must contain to be implementable on any platform — anatomy, states, behaviour and accessibility intent written as intent, not markup — and how tokens reach each platform from one source.
Show how you keep three implementations aligned in practice: a parity table, spec versions per platform, shared acceptance scenarios, and documented deviations where the platform convention should win.
Weigh where shared code is worth it — a cross-platform mobile framework, web views for rare screens — against native fidelity, and set the rule for when a platform may diverge from the shared spec.
## Why the web library's code stops at the platform line A **component library** for the web is code that runs in a browser: it produces web markup, styles and scripts. A **native mobile app** draws its interface with the platform's own UI toolkit, so the web library's components cannot become native controls. A native app *can* host a web view and show web components inside it, but that screen then behaves like a web page inside a native shell — navigation, gestures, scrolling feel and platform conventions can drift from the rest of the app — so most design systems do not deliver their components to native apps that way. Take a multiplayer game's **companion app**: a web clan portal, plus native apps on the two major mobile platforms for match alerts, loadouts and squad chat. The useful question is not "how do we ship our web components to mobile?" but "what do all three implementations agree on, and where are they free to differ?" ## What crosses the line: the design contract | Artefact | Shared across platforms? | How each platform receives it | |---|---|---| | **Design tokens** (color, type, spacing, radius, elevation, motion) | Yes, from one source | A token build step exports them in each platform's native format | | **Component spec**: anatomy, variants, sizes, states | Yes | Documentation and the design-editor library | | **Behaviour contract**: what happens on activate, dismiss, error, loading | Yes | The spec plus shared acceptance scenarios | | **Accessibility contract**: role, accessible name, announced states, focus order | Yes, as intent | Mapped to each platform's accessibility services | | **Names**: component, variant and state names | Yes | Shared vocabulary in the spec | | Component code, rendering, event handling | No | Rebuilt per platform | **Design tokens** are the cheapest thing to share because they are just named values, not code. One source keeps the squad-chat bubble the same surface color and corner radius on the web and on both mobile platforms, and a rebrand changes one file instead of three codebases. The **component spec** carries everything a token cannot: which parts a component has, which variants exist, which states it can be in, and what each interaction does. A spec written as intent ("the dismiss action closes the invite and returns focus to what opened it") can be implemented on any platform; a spec written as web markup cannot. ## What each native team rebuilds - **Rendering** with the platform's toolkit, usually starting from the native control closest to the spec rather than drawing from scratch. - **The input model**: touch gestures, hardware keyboards, the platform's back navigation, haptics. - **Platform settings**: the user's text-size setting, the reduced-motion setting, increased-contrast options. The spec and tokens define the default; the platform scales or adjusts it at runtime. - **Accessibility integration**: exposing the role, name and state from the spec through the platform's accessibility services so its screen reader announces them. - **Platform idioms** where the spec explicitly allows them: a native date picker, a native share sheet, swipe actions on list rows. ## Keeping the implementations aligned 1. **Share the names.** The same component, variant and state names appear in the design editor, the web library and both native libraries. 2. **Treat the spec as the source of truth**, versioned, and record which spec version each platform implements. 3. **Publish a parity table**: per component and per platform, available, partial or not yet built. 4. **Write acceptance scenarios in plain language** that every platform's tests can express in their own tooling. 5. **Document intentional deviations** in the spec itself, so a difference is a decision rather than an accident. ## A worked example: the match-invite card The spec for the match-invite card defines its anatomy (avatar, player name, game mode, countdown, accept and decline actions), its states (pending, expiring, accepted, expired), its behaviour (the invite expires when the countdown ends) and its accessibility intent (the card is announced with the player name and mode; both actions have names that say what they do). Tokens give it the same surface, spacing, radius and type styles everywhere. The web team builds it in its UI framework. Each native team builds it in its own toolkit and adds a swipe-to-decline gesture as an extra path, recorded in the spec as a platform deviation that keeps the visible decline action. ## What this is not Some organisations use a cross-platform mobile UI framework so that the two mobile platforms share one codebase. That reduces two native implementations to one, but the web library still stays separate, and the shared mobile codebase still consumes the same tokens and specs. The model does not change: **share the contract everywhere, share code only where the runtime is the same.**
- When is it acceptable for the native version of a component to deviate from the shared spec?When the platform has a strong convention users rely on — its own date picker, back navigation, share sheet or swipe actions — and matching the web would feel foreign. The deviation should be written into the spec as a platform variant, keep the same name, states and accessibility intent, and still use the shared tokens wherever the native control allows styling.
- Why not show the web components inside a web view in the native app?It works for rarely used, content-heavy screens and some teams accept it there. For core flows the cost is that those screens behave like web pages inside a native shell: navigation, gestures, scrolling feel and platform conventions can drift from the rest of the app. Most systems rebuild frequently used components natively against the spec instead.
saying these in an interview costs you the question
- Native apps should import the web component library's code directly.
- Sharing tokens means web and native screens must be pixel-identical.
- Native mobile needs its own separate design system with its own names.
- The web implementation is the spec; native teams copy whatever it does.
- Native components need no accessibility contract because the platform handles it.