Cover how many platforms for your design system
This question seems technical but is actually a business question: where are your customers using the product the most.
You should decide based on where customers actually use the product, not add more platforms just because it sounds professional. Tokens (design values like color, spacing, typography) can share a single source across multiple platforms through an automated conversion step. However, components (complete interface blocks like buttons, forms) are separate work units for each platform. The effort to build and maintain increases with the number of platforms you add.
- most customers use the original app, which is the main revenue channel
- creating a common token first, then developing components for each platform gradually
- Digital products like websites and apps are not worth investing in yet.
- a technical team not yet sufficient to support multiple platforms
This question often arises when you start building a design system and realize that your product is not just a website. The answer does not lie in technology; it lies in where your customers are using the product and which channels are actually generating revenue.
Tokens and components: two different stories.
Before making a decision, you need to clearly distinguish between the two layers in the design system:
- Token refers to foundational design values: colors, spacing, font sizes, shadows. Tokens do not belong to any specific platform; all platforms can share them.
- Component refers to complete interface blocks such as buttons, navigation bars, and input forms. Components are built using specific technologies and tied to specific platforms.
Multi-platform coverage at the token layer is entirely feasible. A neutral token set according to DTCG standards can output CSS for the web, color variations for iOS, and dp and sp units (standard length units on Android) for Android through tools like Style Dictionary without manually copying each value. Components are different: each platform is a separate block of work, built according to the specific technology that platform uses.
A source token, multiple platform outputs through the transformation step, maintaining consistency without manually copying everywhere.
Style Dictionary, Amazon Web Services
When to expand to iOS and Android
You should cover both iOS and Android when the following conditions are met:
- Most customers actually use the native app, not access it through a mobile browser.
- The application is the main revenue channel, not a supplementary channel for the website.
- The technical team has enough members to build and maintain all three component sets (web, iOS, Android) simultaneously in the long term.
Additional note: iOS and Android have their own underlying languages. Apple has HIG (Human Interface Guidelines), and Android has Material Design. These are conventions that users of each platform are accustomed to, and you should not directly transfer web interfaces into native applications while ignoring these conventions.
When to only cover the web first
In most practical cases, the main digital product is still the web or web app (browser-based application). Mobile applications are either non-existent or not yet the primary channel. In that case, investing in both iOS and Android right away is an investment in something unnecessary, while the needed areas are not being done well.
A more reasonable approach: build a standard and neutral token from the start, create web components correctly first, and develop components for other platforms gradually as real demand arises. Creating a good token from the beginning often does not cost more than creating a thoughtless token, but saves a lot of effort later when scaling. Two questions worth answering before finalizing the scope: in the next six months, which product will have the most users, and how many engineers will regularly dedicate time to the design system?
Web and both iOS, Android: Tokens can be shared, but components for each platform are separate units. The effort to build and maintain truly multiplies with the number of platforms. This is suitable when the app is the main revenue channel and the team has enough people to maintain it.
Common errors when determining the scope
- Expecting web components to be reused exactly on the original iOS or Android application: this does not happen, as these are two different technologies and behaviors.
- Covering multiple platforms when the technical team is understaffed for long-term maintenance results in underutilized platforms being neglected, tokens becoming misaligned, and components not being updated.
- Skipping the automatic transformation step, manually copying token values to each platform: this is the source of discrepancies between platforms over time.
- The decision to cover multiple platforms because it sounds professional, not because there is a real demand from users and the technical team.
Decision checklist
Topic: Only covering the web or needing both iOS and Android for the design system. Sinh Vũ's guide, sinhvu.com
Tick each item that applies or that you can already answer, then print or save as PDF to take with you.
If you have marked most of the signs above, this is the time to discuss in more detail. Sinh Vũ can help you review and propose a direction.
References
Style Dictionary, open source from Amazon. Style Dictionary Transforms documentation. Apple Human Interface Guidelines. Google's Material Design.
Frequently asked questions
Can tokens be shared between the web and the native app?
Yes, at the token level it is feasible. A neutral token set according to DTCG (Design Token Community Group, an organization that standardizes design tokens) can output CSS for the web, color variables for iOS, and dp and sp units for Android through tools like Style Dictionary without manual copying. However, components cannot be shared between web and native applications; each platform requires a separate set built for that specific technology.
If using React Native or Flutter, does the problem change?
The difference is significant. Cross-platform applications like React Native or Flutter are not pure native iOS or Android applications, so components can be shared more within the same stack. However, each component still needs to be carefully checked because the interface behavior on iOS and Android differs according to the conventions of each operating system.
This article is for reference. The scope, pricing, and specific commitments of Sinh Vũ are detailed in the proposal and signed contract.