Covers how many platforms for your design system.
A question that seems technical but is actually a business question: where do customers use your products the most?
Decisions should follow where customers actually use the product, without adding additional platforms just for the sake of professionalism. Tokens (design values such as color, spacing, typography) can share a single source across multiple platforms through automatic conversion. However, components (complete interface blocks like buttons, forms) represent separate work for each platform, with costs and maintenance efforts multiplying according to 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 appears when you start building a design system and realize that your product is not just a website. The answer does not lie in the technical aspects; it lies in where your customers are using the product and which channels are truly generating revenue.
Tokens and components: two different stories.
Before deciding, you need to clearly distinguish the two layers in the design system:
- Token are foundational design values: colors, spacing, font sizes, shadows. Tokens do not belong to any specific platform; they are a common language.
- 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
Sinh Vũ recommends that you cover both iOS and Android when simultaneously meeting the following conditions:
- 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 cases that Sinh Vũ encounters, the primary digital product is still a website or web app (a browser-based application). Mobile applications are either non-existent or not yet the main channel. In that case, covering both iOS and Android is an investment in something unnecessary, while the areas that need attention are not being addressed well.
A more reasonable approach: build a standard and neutral token from the start, create web components correctly first, and gradually develop components for other platforms as real needs arise. Creating a good token from the beginning does not cost more than creating a thoughtless token, but saves a lot of effort later when scaling.
Website and both iOS, Android: Shared tokens are usable, but components for each platform are separate. Maintenance costs and efforts multiply according to the number of platforms. Suitable when the app is the main revenue channel and the team is adequately staffed.
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.
The viewpoint of Sinh Vũ
When consulting and quoting, Sinh Vũ clearly defines boundaries: a neutral DTCG standard token can cover multiple platforms, which is something that should be done correctly from the start even if you currently only have a website. Components are built according to the actual technology you use, without promising a one-size-fits-all solution. A package with larger multi-platform components is more extensive than a single stack package because that reflects the actual workload, not just a mechanical multiplication.
A question Sinh Vũ often asks clients before finalizing the scope is: in the next six months, which product will be used by the most people, and how many team members regularly dedicate time to the design system? The answer will determine a more reasonable foundational scope than any technical reason.
Decision checklist
Topic: Should the design system cover web only or include both iOS and Android? Sinh Vũ guide, sinhvu.com
Select each item you find appropriate, 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, a standardization organization for design tokens) can output CSS for the web, color changes for iOS, and dp and sp units for Android using tools like Style Dictionary without manual copying. However, components cannot be shared between web and native applications; each platform requires its own 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.