Enum-driven, multi-brand, AI-friendly
I build and maintain several apps: Cuisine de Chez Nous, FUT Evolution, Afrique Sports, and more. Each one had its own UI code, its own color definitions, its own button styles. Every time I updated a pattern in one app, I had to remember to replicate it in the others. The result was duplicated effort, visual inconsistencies, and maintenance that scaled linearly with every new project.
I needed a shared design system that could power all of these apps with different brand identities but the same underlying components. One Swift Package, multiple brands, zero duplication.
There was a second motivation: I wanted the system to work with AI. If I specify a brand and a style, an AI agent should be able to generate full screens that respect the token system, use the correct components, and produce code that compiles without manual cleanup. That required making the architecture explicit, documented, and machine-readable from day one.
The core idea is simple: every theme is the product of two enums. Brand selects the raw color palette. Style selects the color mode and shape language (light/dark, rounded/sharp). Together, Brand x Style produces 16 distinct theme combinations from just 4 brands and 4 styles. Changing either enum at the app root transforms the entire interface instantly.
The library ships 58 production-ready components organized into 10 categories: core elements (Text, Icon, Badge), actions (Button, Chip, Toggle), inputs (TextField, SearchField, DatePicker), pickers (SegmentedPicker, CalendarGrid), navigation (TopAppBar, BottomNavOverlay, TabView), feedback (Alert, Banner, ProgressCircle), cards (Card, ProductCard, EventCard, MetricCard), media (Avatar, PhotoGrid, VideoPlayer, Carousel), lists (ListItem, FeedPost), and charts (BarChart, LineChart, SemiCircularGauge, and more).
Components are not thin wrappers. They are highly customizable through enums for variants, styles, sizes, and states. A single DSButton supports six visual styles, three sizes, leading and trailing icons, loading states, and full accessibility labeling.
Every visual property flows through three layers: primitive tokens (raw color values per brand, spacing scale, radius scale), semantic tokens (role-based mappings that change per style, so dark mode inverts the neutral scale and swaps primary/secondary colors), and component tokens (consumed directly by DS components). No magic numbers. No hardcoded hex values. Every pixel traces back to a named token.
The entire system ships as a single Swift Package with zero third-party dependencies. Add it to your project, set the brand and style at the root of your view tree, and every component reads the resolved theme from the SwiftUI environment. No CocoaPods, no Carthage, no build configuration headaches.
The repository includes a CLAUDE.md file with full architecture context and a set of YAML design contracts in the docs/ai/ directory. These contracts describe every component's properties, accepted values, and token bindings in a structured format. When an AI agent reads these files, it can generate correct, compilable SwiftUI code without guessing at token names or property types.
The Figma source file contains all components as proper Component Sets with variants, auto-layout, and design tokens bound to variables. A custom pipeline reads Figma design context output, maps every property to the correct Swift token, and generates production code. The pipeline enforces a zero-hallucination policy: every value must come from the Figma data. If a value is missing, it stops and asks rather than guessing.
A dedicated showcase app (VitrineApp) lets you browse all 58 components across all 16 brand/style combinations. It serves as both a visual reference and a living test suite, making it easy to spot regressions when tokens or components change.
The SwiftUI implementation is the foundation. Next steps include an Android version built with Jetpack Compose, a web version built with React and CSS custom properties, additional components as new app screens demand them, and a public documentation site so other developers can explore the system and its architecture.