DesignFoundation — a token-based SwiftUI design system for Swift 6

Community Showcase
,
1

Hi all,

Sharing DesignFoundation, a SwiftUI design system I've been building. Free, MIT licensed, Swift 6 concurrency safe, targeting iOS 18+, macOS 15+, and visionOS 2. Repo is at https://github.com/NerdSnipe-Inc/design-foundation.

The problem I kept hitting

Every SwiftUI project ends up rebuilding the same primitives: styled buttons, form inputs with validation states, card containers, modals with proper focus handling. Then the design system inevitably drifts because there's no single source of truth for spacing, radius, color, or elevation. Six months in, half the app uses one theme and half uses whatever the busy dev shipped that sprint.

DesignFoundation is my attempt to make the tokens the source of truth and let components compose from them.

What it looks like

One DFTheme at the app root themes every component underneath:

import DesignFoundation

@main
struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            RootView()
                .dfTheme(.default) // or your own DFTheme
        }
    }
}

struct SignInView: View {
    @State private var email = ""

    var body: some View {
        VStack(spacing: .dfSpacing(.md)) {
            DFTextField("Email", text: $email)
            DFButton("Continue", style: .primary) { /* ... */ }
        }
        .padding(.dfSpacing(.lg))
    }
}

Change the theme and every component updates. Switch to Liquid Glass and every surface picks it up. All spacing, radius, and color reads from the same token set.

What's in the OSS core

  • Buttons, inputs, cards, modals, toasts, menus
  • Protocol-based styles so you can extend with your own
  • Token-based theming (spacing, radius, color, typography, elevation, motion)
  • Built-in themes including a Liquid Glass style
  • Swift 6 strict concurrency, no Sendable warnings

Install via SPM:

.package(url: "https://github.com/NerdSnipe-Inc/design-foundation.git", from: "1.1.1")

Design decisions I'd love feedback on

  • The theme is a value type applied via environment, not a shared singleton. Overriding for a subtree (.dfTheme(.dark)) works the way Font and ForegroundStyle do
  • Component styles use protocols, not closures — so you can implement DFButtonStyle and share it across apps
  • Tokens are stored as semantic scales (.dfSpacing(.md)) rather than raw values, letting the theme redefine what md means per brand

I'm still open on:

  1. Whether protocol-based styles feel Swift-idiomatic or over-engineered for your projects
  2. Whether the semantic token scale is the right abstraction or if raw values with theme-defined constants would be simpler
  3. What components you'd want in the OSS core that aren't there yet (I've heard requests for date pickers, complex data tables, and a proper file picker)

Links

Happy to answer anything. Feedback welcome, especially on the three design decisions above.

Daniel

4 Likes