expo-design-system

Create a src/theme directory with token files for colors, spacing, typography, radius, shadows, and motion, re-exported from one index entry point. Then build reusable components in src/components with variant, size, and state props that consume only those tokens.

Run grep checks for hex colors, raw fontSize values, non-scale spacing numbers, and legacy shadow props outside the theme directory. Score each category as escapes per 100 source lines, then migrate incrementally starting with typography, one screen per commit.

Yes. If a styling library already exists in package.json, it is the source of truth and should be extended in its own idiom rather than replaced. For Tailwind projects, tokens live in global.css as CSS variables while the same scales and naming apply.

Extract only when the view appears in two or more screens, has a nameable role like Card or EmptyState, and its props API is smaller than its implementation. Move it stepwise from inline JSX to the screen folder to src/components, never speculatively.

Common tells include custom centered web-style modals, emoji used as icons, purple-gradient heroes, every row wrapped in a shadowed card, and uniform 16px padding everywhere. The references/native-slop.md catalog lists 20 named anti-patterns with grep checks and native replacements.

No. Platform components that already carry the design language, such as Switch, DateTimePicker, stack headers, and @expo/ui views, should not be wrapped just to route them through the system. Native styling is the design system for those controls.