atomic-design-ios_skill

Overview

This skill provides expert guidance for applying Atomic Design to iOS and tvOS projects using SwiftUI. It helps you decide when a component hierarchy adds value versus when it is overkill, how to draw atom vs molecule boundaries, and how to manage design tokens and component reuse across apps and teams.

How this skill works

It codifies decision trees and concrete rules: when to adopt a full Atomic hierarchy based on system size, how to decide extraction scope (one-off, local, design system), and explicit token naming and usage patterns for colors, spacing, and typography. The skill highlights anti-patterns (magic numbers, components that know app state, skipped composition levels) and offers composable patterns and token structures you can apply directly in SwiftUI.

When to use it

• Structuring a new design system or evolving an existing one
• Deciding whether to extract a view into an atom, molecule, or organism
• Defining or auditing design tokens for colors, spacing, typography, radii, and shadows
• Working across multiple teams or features where component reuse and consistency matter
• Cleaning up components that have too many parameters or hidden app dependencies

Best practices

• Match hierarchy to scale: skip formal Atomic structure for very small systems, adopt full hierarchy for large systems (30+ components, multiple teams)
• Atoms should be presentational and receive state via parameters — never depend on environment or fetch data
• Use tokens for every themeable value (Spacing.xs..xl, Color.semantic/brand, Font tokens, Radius enums) and avoid magic numbers
• Extract components based on reuse: inline for single-use, local for 2–3 uses, design-system level for 4+ or cross-feature reuse
• Prefer focused variants over a single component with many parameters; split responsibilities to keep APIs simple

Example use cases

• Deciding whether a complex search bar becomes a molecule or remains an atom
• Converting repeated inline cards into a Card molecule with content/footer slots
• Choosing token names for semantic colors (interactive, surface, error) to support theming and dark mode
• Auditing a component library to remove magic numbers and centralize radii and spacing tokens
• Designing button variants (PrimaryButton, IconButton, LoadingButton) instead of a single over-parameterized button