As a Senior iOS Engineer, I've worked on apps where every screen used slightly different shades of blue, buttons had inconsistent padding, and typography was scattered across dozens of hardcoded values. It works, until it doesn't. Refactoring becomes painful. Onboarding new developers takes longer. Design consistency slowly erodes.

So I decided to build a proper design system. Not just a collection of components, but a layered architecture with design tokens, reusable primitives, and clear API patterns.

The project is open source: SwiftUIDesignSystem on GitHub

Why Build a Design System?

Three reasons:

1. Consistency — Every button, every card, every text style comes from the same source. Change it once, it updates everywhere.

2. Speed — Once the foundation exists, building new screens is faster. You're composing, not creating from scratch.

3. Shared Language — Designers say "use medium spacing" and developers know exactly what that means: 16 points.

Layer 1: Design Tokens

Design tokens are the foundation. They're named values—not raw numbers—that represent your design decisions.

Colors

Instead of scattering Color(hex: "007AFF") throughout the codebase, I define semantic colors:

public enum DSColors {
    public static let primary = Color(hex: "007AFF")
    public static let destructive = Color(hex: "FF3B30")
    public static let success = Color(hex: "34C759")

    public static let textPrimary = Color(hex: "000000")
    public static let textSecondary = Color(hex: "6B7280")

    public static let backgroundPrimary = Color(hex: "FFFFFF")
    public static let backgroundSecondary = Color(hex: "F3F4F6")
}

Now when I need a color, I use DSColors.primary—not a magic hex string.

Spacing

I use a 4-point grid. Every spacing value is a multiple of 4:

public enum DSSpacing {
    public static let xxs: CGFloat = 4
    public static let xs: CGFloat = 8
    public static let sm: CGFloat = 12
    public static let md: CGFloat = 16
    public static let lg: CGFloat = 24
    public static let xl: CGFloat = 32
}

Usage is simple:

VStack(spacing: DSSpacing.md) {
    // content
}
.padding(DSSpacing.lg)

No more guessing whether that padding should be 14, 16, or 18 points.

Layer 2: Components

With tokens in place, I build components on top of them.

DSButton

A button with four styles (primary, secondary, destructive, ghost), three sizes, loading state, and built-in accessibility:

DSButton("Get Started", style: .primary) {
    // action
}

DSButton("Delete", style: .destructive, isLoading: true) {
    // action
}

DSText

A typography component that enforces consistent text styles:

DSText("Welcome", style: .title1)
DSText("Subtitle here", style: .body, color: .secondary)

It maps to SwiftUI's built-in text styles, so Dynamic Type works automatically.

DSCard

A container component using @ViewBuilder to wrap any content:

DSCard(hasShadow: true) {
    VStack(alignment: .leading, spacing: DSSpacing.sm) {
        DSText("Card Title", style: .headline)
        DSText("Card content goes here.", style: .body, color: .secondary)
        DSButton("Action", style: .primary) { }
    }
}

What I've Learned So Far

Start with tokens, not components. It's tempting to jump straight into building buttons and cards. But without tokens, you'll hardcode values and lose consistency.

Keep the API simple. A component that requires 10 parameters to use won't get used. Sensible defaults matter.

Previews are essential. Xcode previews let me see every component variant without running the app. I add multiple #Preview blocks to each component.

What's Next

I'm continuing to build out the component library:

• DSTextField (input with validation)

• DSToggle (accessible switch)

• DSAlert (contextual messages)

• DSBadge (status indicators)

The goal is a production-ready system that I—or anyone—can drop into a real app.

Follow the progress on GitHub, or connect with me on Twitter/X.