/cross-platform-design

name: cross-platform-design
description: Use when the user wants one codebase or one product design across web, iOS, Android, Windows, and Mac, asks for the same app on all platforms, asks to translate/port a UI between platforms, or names Compose Multiplatform, Tauri 2, Electron, React Native, Flutter, .NET MAUI, Avalonia, or Uno Platform. Builds cross-platform UI by preserving UX decisions, originality seed, desktop archetype, state coverage, tokens, and product job while translating each surface into the host platform's native idiom rather than pixel-cloning. SKIP when only one platform is targeted and no translation/cross-platform tradeoff is involved.

cross-platform-design — translate idiom, not pixels

Goal: ship one codebase that respects each platform's HIG/Material/Fluent — not a Flutter app that looks like Flutter on every OS.

What This Skill Can Do

• Choose cross-platform stacks and explain tradeoffs across Tauri, Electron, React Native, Flutter, Compose Multiplatform, Avalonia, Uno, and MAUI.
• Translate Apple, Android, Windows, and web patterns by idiom instead of copying pixels.
• Preserve UX briefs, state coverage, action hierarchy, tokens, desktop archetype, originality seed, layout sketch, and product metaphor across platforms.
• Define per-platform navigation, controls, typography, icons, motion, density, and accessibility adaptations.
• Warn when one shared UI will harm platform fit or when a single-platform implementation is the better choice.

Step 0 — Preserve UX and UI decisions

If Stark produced a UX decision brief or UI decision brief, keep both as the source of truth. Translate them per platform instead of pixel-cloning.

Read:

• `../../references/ui-patterns/surface-taxonomy.md`
• `../../references/ui-patterns/ui-decision-brief.md`
• `../../references/ui-patterns/desktop-app-archetypes.md`
• `../../references/ui-patterns/native-desktop-app-quality-contract.md`
• `../../references/ui-patterns/originality-engine.md`
• `../../references/ui-patterns/design-recipes.md`
• `../../references/ui-patterns/anti-default-contrasts.md`
• `../../references/ui-patterns/visual-hierarchy.md`
• `../../references/ui-patterns/motion-budget.md`

The shared product should preserve job, state coverage, action hierarchy, visual hierarchy, desktop archetype, native desktop quality decisions, originality seed, and layout sketch. Navigation, controls, typography, icons, and motion must become platform-specific, but the chosen shape should remain legible: command center stays a command center, library stays a library, workbench stays a workbench, and monitoring cockpit stays a monitoring cockpit. Desktop targets still need per-platform window model, command model, native controls, resize behavior, keyboard/focus paths, and platform evidence. A product-specific metaphor can translate across platforms; exact pixels and custom controls should not.

Step 1 — Pick the right framework for the design intent

| User priority | Recommended stack | |---|---| | Native feel + Kotlin codebase + iOS support | **Compose Multiplatform 1.8+** (iOS stable since May 2025) | | Tiny binary, web team, desktop-first | **Tauri 2** (Rust + native webviews; ~3MB) | | Native Android views + iOS, large ecosystem | **React Native** (New Arch + Fabric + Hermes) | | Single Skia raster across platforms (custom design system) | **Flutter** — only if pixel control matters more than native feel | | .NET shop, XAML cross-platform | **Uno Platform 5+** (reuses WinUI XAML) | | .NET shop, mobile-first | **.NET MAUI** (warn: weaker desktop, weaker iOS feel) | | Cross-platform desktop + custom theming | **Avalonia 11** with Fluent/Mac themes |

Step 2 — Native-feel ranking by platform

When the user picks a stack, **state the fidelity tradeoff per platform** in one line each.

Compose Multiplatform 1.8+

• Android: native (excellent)
• iOS: stable but Material widgets won't feel HIG — you must implement Cupertino-styled Compose components, or accept a Material aesthetic on iOS
• Desktop: good for Compose-driven design, not native Fluent
• Web (Wasm): experimental

Tauri 2

• Windows: WebView2 chrome — Mica works via window-backdrop API but font rendering and focus rings will look subtly off vs WinUI 3
• macOS: WKWebView — looks like a web app, not an AppKit/SwiftUI app
• Linux: WebKitGTK
• Mobile (iOS/Android): preview, not production-ready

React Native (New Architecture)

• iOS: real UIKit views, decent. Liquid Glass requires `expo-glass-effect` or native modules; partial adoption.
• Android: real Android views, M3 themable but won't get spring physics or shape morphing without manual work.
• Desktop: react-native-windows / react-native-macos exist, fidelity weaker

Flutter

• All platforms: Skia custom-painted. Never feels native to anyone.
• Material 3 widgets exist but lag platform updates (no spring physics parity, no shape morphing primitives, no real dynamic color).
• **Avoid** for any project where "native feel" is a stated requirement.

Uno Platform

• Windows: native WinUI (excellent)
• iOS / Android / Mac / Web: reuses XAML rendering — distinctive fidelity but not 1:1 with each platform's idiom
• Best XAML cross-platform path

.NET MAUI

• Windows: weak WinUI integration
• macOS: Catalyst (deprecated direction)
• iOS: looks like Android in costume
• **Generally avoid for design-first work**

Step 3 — Translation rules: same product, different idiom

**Settings screen example:**

• iOS → grouped `Form` with `Section { ... }` headers, Liquid Glass toolbar, switch toggles
• Android → `LargeTopAppBar` + `LazyColumn` with `ListItem` rows, switches with M3 thumbs
• Windows → `NavigationView` + scrollable `SettingsCard` stack with Mica backdrop
• Web → asymmetric grid with sidebar nav and editorial section headers

**Tab bar example:**

• iOS → bottom `TabView` (5 tabs max, Liquid Glass)
• Android → `NavigationBar` (3–5) or `NavigationRail` adaptive
• Windows → `NavigationView` T