Guide for building SwiftUI components using Brad Frost's Atomic Design methodology — organizing views into Atoms, Molecules, Organisms, Templates, and Pages with Design Tokens for theming. Use this skill whenever building new SwiftUI UI components, refactoring existing views into reusable pieces, creating a design system, or organizing a component library. Also trigger when the user mentions "atomic design", "design system", "component hierarchy", "reusable components", "atoms and molecules", "design tokens", or wants to decompose a complex SwiftUI view into smaller, composable parts, or needs to implement theming/customization across a SwiftUI app.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Guide for building SwiftUI components using Brad Frost's Atomic Design methodology — organizing views into Atoms, Molecules, Organisms, Templates, and Pages with Design Tokens for theming. Use this skill whenever building new SwiftUI UI components, refactoring existing views into reusable pieces, creating a design system, or organizing a component library. Also trigger when the user mentions "atomic design", "design system", "component hierarchy", "reusable components", "atoms and molecules", "design tokens", or wants to decompose a complex SwiftUI view into smaller, composable parts, or needs to implement theming/customization across a SwiftUI app.
SwiftUI Atomic Design System
Atomic Design is Brad Frost's methodology for building UI systems from small, composable pieces. In SwiftUI, this maps naturally to the framework's declarative, compositional view architecture. The hierarchy flows from simple to complex:
Each level composes the one below it. Design Tokens provide the visual foundation that all levels reference. The discipline is knowing where a component belongs — that's what makes the system scalable, consistent, and maintainable.
Design Tokens — The Visual Foundation
Design tokens are the centralized source of truth for all visual properties: colors, typography, spacing. They sit beneath atoms — every component references tokens rather than hardcoding values. This ensures consistency across the entire design system and makes sweeping visual changes (rebranding, dark mode, accessibility) a single-point update.
Why tokens matter:
Change a brand color once, and it propagates everywhere
Enable theming (light/dark, high contrast) without touching component code
Create a shared vocabulary between design and development
Tokens become powerful when combined with SwiftUI's Environment system for runtime theming. Define theme variants and inject them through the environment so every component adapts automatically.
Components read from @Environment(\.appTheme) instead of hardcoding colors, making the entire UI theme-switchable.
The Hierarchy
Atoms — Single-responsibility UI primitives
An atom is the smallest meaningful UI element. It does one thing and has no awareness of its context. Atoms reference Design Tokens for all visual properties — they never hardcode colors, fonts, or spacing.
What qualifies as an atom:
Renders a single visual concept (a badge, an icon, a divider, a label, a button)
Takes only primitive/value-type inputs (String, Color, Bool, CGFloat, enums)
Has zero business logic — purely presentational
Never reads from Environment or stores (except theme tokens)
References Design Tokens for all visual values
SwiftUI patterns for atoms:
Small structs, typically 10–30 lines
Use computed properties for style variants rather than complex switch statements in body
Proportional sizing (e.g., size * 0.5) so atoms scale naturally
// Atom: Colored SF Symbol in a rounded squarestructIconBadge: View {
let icon: Stringlet color: Colorvar size: CGFloat=28var body: someView {
Image(systemName: icon)
.font(.system(size: size *0.5, weight: .medium))
.foregroundStyle(color)
.frame(width: size, height: size)
.background(color.opacity(0.12))
.clipShape(RoundedRectangle(cornerRadius: size *0.21))
}
}
// Atom: Styled text with token-based typographystructTitleText: View {
let text: Stringvar body: someView {
Text(text)
.font(DesignTokens.Typography.title)
.foregroundStyle(DesignTokens.Colors.textPrimary)
}
}
Common atoms: badges, pills, dividers, icon wrappers, character counters, section headers (text-only), card backgrounds, simple labels, primary/secondary buttons, text field wrappers.
Molecules — Functional combinations of atoms
A molecule combines 2–3 atoms (or atom-level elements) into a unit that serves a single user purpose. Molecules are the backbone of the design system — they create the reusable patterns that appear throughout the app. The key test: does this combination appear in multiple places?
What qualifies as a molecule:
Combines atoms into a meaningful group (icon + label + value)
Serves one user-facing function (show info, trigger action, display status)
May accept closures for actions, but doesn't manage state itself
Can accept @Binding for two-way data flow (e.g., text fields)
Can accept domain types if they simplify the API, but the view itself stays presentational
Common molecules: info rows, action buttons with labels, search bars, form fields with validation, stat cards, option/toggle rows, tip views, labeled input fields.
Organisms — Complex, self-contained UI sections
An organism is a distinct section of the interface that could stand alone. It composes multiple molecules (and atoms) into a cohesive unit. Organisms form the significant parts of your UI — login forms, navigation bars, metric dashboards. This is where you introduce @ViewBuilder content slots and section-level structure.
What qualifies as an organism:
Represents a visually distinct region (a section, a card group, a toolbar, a form)
Composes multiple molecules into a layout
May use @ViewBuilder for content injection
May read from @Environment for contextual data
Can manage local UI state (@State for expand/collapse, selection, etc.)
Common organisms: content sections, form groups, navigation bars, card lists, detail panels, metric dashboards, grouped settings, login forms.
Templates — Page-level layout scaffolding
A template defines the spatial arrangement of organisms on a screen. It's the skeleton — it knows where things go but not what specific data fills them. Templates use generics and @ViewBuilder heavily. They handle page-level concerns like loading states, empty states, and error states.
What qualifies as a template:
Defines the overall page structure (ScrollView, navigation, toolbars)
Arranges organism-level slots using generic view parameters
Handles page-level concerns: loading states, empty states, error states
Does NOT contain specific data — that's the Page's job
// Template: Main layout with navigation bar and content areastructMainLayout<Content: View>: View {
let title: String@ViewBuilderlet content: Contentvar body: someView {
VStack(spacing: 0) {
// Navigation bar (organism)HStack {
Image(systemName: "arrow.left")
Spacer()
Text(title).font(DesignTokens.Typography.headline)
Spacer()
Image(systemName: "gear")
}
.padding(DesignTokens.Spacing.md)
.background(DesignTokens.Colors.primary)
content
.padding(DesignTokens.Spacing.md)
Spacer()
}
.background(DesignTokens.Colors.background)
}
}
Pages — Templates filled with real data
A page is a specific instance of a template, wired to real data and business logic. This is where @Observable objects, @Environment, and navigation live. Pages are what users actually interact with — they assemble templates, inject data, and handle user actions.
Is it a visual constant (color, font, spacing)? → Design Token
Does it render a single visual element with no children? → Atom
Does it combine 2–3 simple elements for one purpose? → Molecule
Does it represent a distinct UI section with internal structure? → Organism
Does it define page layout without specific data? → Template
Does it wire a template to real data and business logic? → Page
Gray areas:
A section header with just icon + title = Atom (single concept: "label this section")
A section header with icon + title + subtitle + action button = Molecule (multiple atoms combined)
A collapsible section with header + content slot = Organism (manages state, contains others)
A labeled text field = Molecule (combines label atom + text field atom)
A login form with multiple fields + button = Organism (composes multiple molecules, manages @State)
SwiftUI-Specific Patterns
ViewModifiers as cross-cutting atoms
When a visual treatment applies across levels (card styling, glass effects), extract it as a ViewModifier rather than duplicating styling. This keeps atoms clean and ensures visual consistency:
Organisms and templates should accept content through @ViewBuilder closures rather than concrete child types. This keeps higher-level components flexible without creating tight coupling:
Use Design Tokens everywhere: Never hardcode colors, fonts, or spacing in components — always reference tokens
Component Library: Build and maintain a library of reusable components at each atomic level
Naming Conventions: Follow consistent naming that reflects the atomic level (e.g., PrimaryButton atom, SearchBar molecule, LoginForm organism)
Modular Design: Break components into the smallest reusable modules
Documentation: Include #Preview blocks and header comments describing atomic level and purpose
Regular Reviews: Periodically audit components to ensure they're at the correct atomic level
Theme Integration
Components should read theme values from @Environment or Design Tokens, never hardcode brand colors
Support light/dark mode through token-based theming
Test all components against every theme variant in previews
Anti-Patterns
Fat atoms: If an atom has more than ~30 lines of body, it's probably a molecule
Molecules with @State: Local UI state belongs in organisms, not molecules. Molecules receive and display, they don't manage
Organisms that know about navigation: Navigation is a page concern. Organisms signal intent via closures, pages handle routing
Templates with hardcoded data: If you see real strings or API calls in a template, the data should move up to the page
Skipping levels: Don't jump from atoms to pages. The intermediate levels exist to manage complexity — skipping them creates monolithic views that are hard to reuse and test
Hardcoded visual values: Using Color.blue or .font(.system(size: 16)) directly in components instead of referencing Design Tokens defeats the purpose of the system
Token-less theming: Building theme support without Design Tokens leads to scattered, inconsistent overrides
File Header Convention
Mark each file's atomic level in the header comment for quick identification:
//// IconBadge.swift// ModuleName//// Atom: Colored SF Symbol in a rounded square//
This makes it easy to verify a file is in the right directory and understand its role at a glance.