Cross-platform design systems: one Figma file, two platforms

Building one design system meant to serve both iOS and Android is a common ask for cross-platform apps, and done carelessly it produces an app that feels foreign on both platforms at once, following neither iOS's nor Android's actual conventions closely enough to feel native to either audience.

The instinct behind a single shared system is a reasonable one, consistency and efficiency, but applied without judgment it produces the worst version of both platforms rather than the best version of either. The goal isn't one identical app running on two operating systems, it's one coherent brand expressed correctly within each platform's own established conventions.

Color palette, type scale, spacing, and brand voice can genuinely be shared across platforms, that's the brand layer. Navigation patterns, specific component behaviors (how a modal presents, how a list item responds to a long press), and certain interaction conventions should respect each platform's own norms, since users bring platform-specific expectations with them regardless of what any individual app does.

We draw this line explicitly at the start of any cross-platform project, listing out which decisions belong to the shared brand layer and which belong to the platform-specific interaction layer, before any actual screens get designed. That upfront list prevents the far more common failure mode, where the line gets redrawn inconsistently screen by screen, decided in the moment by whichever designer happens to be working on it.

We maintain a single design system file with platform-specific component variants clearly labeled, rather than two entirely separate files that inevitably drift out of sync with each other over time. Designers work from one source, choosing the right variant per platform, which keeps the brand layer consistent while still respecting platform-specific interaction patterns.

The alternative, two fully separate files maintained by different designers or even the same designer at different times, reliably drifts within a few months, a color updated in one file and forgotten in the other, a component redesigned on iOS with no corresponding update made to its Android counterpart. A single file with clearly labeled variants removes that drift risk structurally rather than relying on anyone remembering to keep two documents in sync by hand.

A flow that feels natural on iOS doesn't always translate directly to Android, and vice versa, even with a shared design system underneath. We walk through every core flow on a real device on both platforms before sign-off, specifically to catch the moments where a shared design decision doesn't actually feel right in one platform's native context.

This device-based review has caught real problems a Figma review alone missed more than once, an interaction that reads perfectly clearly in a static design file but feels awkward the moment it's actually tapped through on a physical Android device with its own gesture conventions and system-level back button behavior. Nothing replaces actually holding both devices and running the same flow on each before calling a design finished.

Disagreements between platform conventions and brand consistency are inevitable on any cross-platform project, and we assign one person, usually the lead product designer, clear authority to make that specific tradeoff call rather than litigating it fresh every time it comes up. Having a named decision-maker for exactly this recurring tension keeps the project moving without every borderline case turning into a lengthy debate.

We document each of these divergence decisions briefly as they're made, a short note explaining why a particular component deliberately breaks from the shared system on one platform, so a future designer or engineer encountering the inconsistency later understands it was a deliberate choice rather than an oversight worth quietly fixing back into alignment.

A platform-specific design decision that isn't communicated clearly to the engineering team building each platform's app tends to get implemented inconsistently anyway, regardless of how well the design file itself documents the intended divergence. We involve engineers from both platform teams in reviewing the design system's platform variants directly, not just the product designers, since engineers are the ones who ultimately have to implement the platform-specific behavior correctly.

This cross-functional review has caught real implementation gaps before they shipped more than once, a platform variant that looked correct in Figma but that the Android team hadn't realized required a genuinely different underlying component rather than a simple style override on their existing one. Catching that kind of gap in review is far cheaper than catching it after both platforms have already shipped inconsistent behavior to real users.

Post-launch, both platforms' teams keep contributing back to the shared system rather than forking their own local copies once real feature work picks up pace, which requires the same ownership discipline as any shared design system: someone reviewing every proposed addition against both the brand layer and the appropriate platform-specific layer before it's merged in. Without that ongoing review, the two platforms' implementations drift apart again within a matter of months, quietly undoing the coherence the original system was built to maintain.

For teams with two fully separate platform-specific squads, little cross-collaboration, and no realistic plan to unify workflows, a shared system can add coordination overhead that outweighs its consistency benefit. We're honest with clients in that specific situation rather than recommending a shared system on principle alone, since the right structure ultimately depends on how the team is actually organized, not just on what produces the most elegant Figma file.

Even in that case, we still recommend at minimum a shared, lightweight brand reference, colors, type, voice, kept separate from the two platform-specific component libraries, since brand consistency and component-level system consistency are genuinely separable concerns, and giving up on the second doesn't mean giving up on the first.

The apps that feel best to their actual users are rarely the ones that look most identical across platforms in a side-by-side screenshot comparison. They're the ones that feel unmistakably like the same brand while still behaving exactly the way a longtime iOS or Android user already expects an app on their platform to behave. That's a harder design problem than building one flat system twice, but it's the one that actually earns a user's trust on each platform rather than just their tolerance.