Design Tokens in SwiftUI Without Framework Bloat

The confusion

Design tokens are supposed to make UI more consistent. But in a lot of codebases they turn into a second framework, with more abstraction than the feature actually needs.

That is when the system starts helping the tooling more than the app.

What SwiftUI is actually doing

SwiftUI already gives you a strong visual composition model. That means design tokens should usually describe values that are repeated across the app, not replace the framework’s own structure.

Good token layers typically describe:

spacing
color roles
typography scale
corner radii
component intent

They should not turn every UI choice into a custom DSL.

The mental model

Design tokens should reduce repetition, not obscure the shape of the interface.

If a token hides what the UI is doing, it becomes a maintenance burden. If it helps you keep repeated styling aligned, it pays for itself quickly.

That is why the best token systems are small and boring.

A small proof

enum AppSpacing {
    static let section = 16.0
    static let row = 12.0
}

struct TokenCard: View {
    var body: some View {
        VStack(spacing: AppSpacing.row) {
            Text("Title")
            Text("Supporting text")
        }
        .padding(AppSpacing.section)
    }
}

This is enough to show the idea: the token adds consistency, but the SwiftUI structure stays obvious.

Why this matters in real apps

If tokens are too heavy, every screen becomes harder to inspect. If they are too light, style drift spreads.

The middle ground is to keep tokens close to the product language. Then the design system becomes a help, not a hidden layer.

Where this model breaks down

Some design systems need stronger governance than a few constants. That is fine.

But even then, avoid building a framework that forces every screen through a large abstraction just to apply spacing or color.

One sentence to remember

Good design tokens make consistency easier without making the UI harder to read.