Construire un Design System SwiftUI en 2025 : Le Guide Architecte
Publié le · 45 min
En 2025, la question n'est plus "faut-il un Design System ?" mais "comment construire un Design System qui scale ?". Avec l'unification des versions Apple (iOS 26, macOS 26, watchOS 26, tvOS 26, visionOS 26), SwiftUI est devenu le socle universel pour toutes les plateformes. Un Design System bien architecturé n'est plus un luxe — c'est une nécessité pour toute équipe qui veut livrer des produits cohérents, accessibles et maintenables.
Ce guide vous accompagne de la théorie à l'implémentation, avec du code prêt pour la production.
Pourquoi un Design System est devenu impératif
Le coût caché de l'absence de système
Sans Design System, voici ce qui arrive inévitablement :
La dette visuelle s'accumule
- 5 nuances de bleu "primaire" dans l'app
- Des espacements à 12px, 13px, 14px, 16px selon l'humeur du jour
- Des boutons avec 4 styles différents pour la même action
L'accessibilité devient impossible à maintenir
- Contrastes insuffisants découverts en audit
- VoiceOver qui lit "bouton bouton image"
- Dynamic Type qui casse les layouts
Le multi-plateforme devient un cauchemar
- Code dupliqué entre iOS et macOS
- Comportements incohérents sur watchOS
- visionOS ajouté "plus tard" et jamais intégré proprement
Le ROI d'un Design System mature
Les chiffres parlent d'eux-mêmes :
| Métrique | Sans DS | Avec DS mature |
|---|---|---|
Temps création d'un écran | 2-3 jours | 4-8 heures |
Bugs UI/UX par sprint | 15-20 | 2-5 |
Temps d'onboarding dev | 2-3 semaines | 3-5 jours |
Couverture accessibilité | ~40% | 95%+ |
Cohérence cross-platform | Faible | Excellente |
Les 5 piliers d'un Design System SwiftUI moderne
“Référence HIG : Apple structure ses guidelines autour de concepts similaires — Foundations (couleurs, typo, icônes), Patterns (navigation, modals), et Components (boutons, contrôles). Un bon Design System suit cette hiérarchie.”
1. Tokens : La fondation sémantique
Les tokens sont les atomes de votre système. Jamais de valeurs hardcodées.
Standards de l'industrie : Spacing
Les systèmes de spacing professionnels suivent une échelle de 4pt ou 8pt (aussi appelée "4-point grid" ou "8-point grid"). Cette approche est utilisée par :
| Système | Base | Échelle |
|---|---|---|
Apple HIG | 8pt | 8, 16, 24, 32... |
Material Design 3 | 4pt | 4, 8, 12, 16, 24... |
Atlassian | 8pt | 8, 16, 24, 32... |
IBM Carbon | 8pt | 8, 16, 24, 32, 48... |
“Règle HIG : Apple recommande des multiples de 8pt pour le spacing principal, avec 4pt pour les ajustements fins. Cela garantit un alignement pixel-perfect sur toutes les densités d'écran.”
Standards Typography
La typographie iOS suit le système Dynamic Type avec des styles sémantiques :
| Style HIG | Usage | Taille par défaut |
|---|---|---|
Large Title | Titres de page | 34pt |
Title 1 | Sections principales | 28pt |
Title 2 | Sous-sections | 22pt |
Title 3 | Groupes | 20pt |
Headline | Labels importants | 17pt semibold |
Body | Texte principal | 17pt |
Callout | Texte secondaire | 16pt |
Footnote | Mentions légales | 13pt |
Caption | Métadonnées | 12pt |
“Règle HIG : Toujours utiliser les styles sémantiques (Font.headline, Font.body) plutôt que des tailles fixes. Cela garantit le support automatique de Dynamic Type.”
2. Couleurs sémantiques avec Dark Mode natif
Ne jamais utiliser .red ou .blue directement. Toujours passer par des couleurs sémantiques.
Standards couleurs : Sémantique vs Palette
Un Design System mature distingue deux niveaux de couleurs :
1. Palette (primitives) — Les couleurs brutes
2. Sémantique (tokens) — L'intention d'usage
“Règle HIG : Apple fournit des couleurs sémantiques système (Color.primary, Color.secondary, .background) qui s'adaptent automatiquement au contexte (light/dark, contraste élevé). Privilégiez-les avant de créer des couleurs custom.”
Règles de contraste WCAG
Les Web Content Accessibility Guidelines définissent des ratios minimum :
| Niveau | Ratio minimum | Usage |
|---|---|---|
AA | 4.5:1 | Texte normal (< 18pt) |
AA Large | 3:1 | Texte large (≥ 18pt bold ou ≥ 24pt) |
AAA | 7:1 | Texte normal (recommandé) |
AAA Large | 4.5:1 | Texte large (recommandé) |
⚠️ Standard légal : En Europe (EAA 2025) et aux USA (ADA), le niveau WCAG AA est une obligation légale pour les apps grand public. AAA est recommandé mais non obligatoire.
3. Composants atomiques réutilisables
Chaque composant doit être : configurable, accessible, et prévisualisable.
Standards de composants : Atomic Design
La méthodologie Atomic Design (Brad Frost, 2013) structure les composants en 5 niveaux :
| Niveau | Description | Exemple SwiftUI |
|---|---|---|
Atoms | Éléments indivisibles | Text, Image, Color |
Molecules | Groupes d'atomes | DSButton, DSTextField |
Organisms | Sections complètes | DSCard, DSNavigationBar |
Templates | Layouts de page | DSListTemplate, DSDetailTemplate |
Pages | Instances avec données | ProductListView, ProfileView |
“Règle HIG : Apple définit des "Controls" (boutons, toggles, sliders) et des "Patterns" (navigation, search, modals). Un bon composant respecte les comportements attendus par l'utilisateur.”
Tailles de touch targets
| Standard | Taille minimum | Recommandation |
|---|---|---|
Apple HIG | 44×44 pt | 44×44 pt minimum |
Material Design | 48×48 dp | 48×48 dp minimum |
WCAG 2.2 | 24×24 CSS px | 44×44 px recommandé |
“Règle HIG : Tous les éléments interactifs doivent avoir une zone de tap d'au moins 44×44 points, même si l'élément visuel est plus petit. Utilisez .contentShape() ou du padding pour agrandir la zone.”
4. Composants complexes : Card System
Accessibilité : Non négociable en 2025
Dynamic Type complet
Contrastes et couleurs accessibles
Standards d'accessibilité : Les 4 principes POUR
Les WCAG reposent sur 4 principes fondamentaux (acronyme POUR) :
| Principe | Description | Exemple SwiftUI |
|---|---|---|
Perceivable | L'info doit être perceptible | accessibilityLabel(), contrastes |
Operable | L'interface doit être utilisable | Touch targets 44pt, navigation clavier |
Understandable | Le contenu doit être compréhensible | Labels clairs, messages d'erreur explicites |
Robust | Compatible avec les technologies d'assistance | VoiceOver, Switch Control |
“Règle HIG : Apple va au-delà des WCAG avec des features comme Reduce Motion, Increase Contrast, Bold Text, et Reduce Transparency. Un Design System complet doit supporter ces préférences.”
Checklist accessibilité Design System
iOS 26 : Glass Effect et Material Design
iOS 26 introduit de nouveaux effets visuels avec le paradigme Liquid Glass. Voici comment les intégrer proprement dans votre Design System.
Standards iOS 26 : Liquid Glass
iOS 26 introduit le paradigme Liquid Glass qui unifie l'esthétique sur toutes les plateformes Apple :
| Propriété | Description | Valeur recommandée |
|---|---|---|
Blur radius | Flou du background | 20-40pt selon contexte |
Saturation | Vibrance des couleurs | 1.2-1.5× |
Luminosity | Ajustement de luminosité | ±10-20% selon light/dark |
Border | Bordure subtile | 0.5pt blanc semi-transparent |
“Règle HIG iOS 26 : Le glass effect doit être utilisé avec parcimonie — principalement sur les barres de navigation, les sheets, et les overlays. Évitez-le sur les contenus principaux pour maintenir la lisibilité.”
Quand utiliser Glass vs Solid
| Contexte | Recommandation |
|---|---|
Navigation bars | ✅ Glass (ultraThinMaterial) |
Tab bars | ✅ Glass (thinMaterial) |
Sheets/Modals | ✅ Glass (regularMaterial) |
Cards sur fond uni | ❌ Solid (elevated surface) |
Cards sur image | ✅ Glass (pour lisibilité) |
Contenu principal | ❌ Solid (jamais de glass) |
Swift 6 : Concurrency-Safe Design System
Swift 6 enforce la sécurité de la concurrence. Votre Design System doit être prêt.
Architecture modulaire : Swift Package
Structurez votre Design System en package Swift pour une réutilisation maximale.
Multi-plateforme : Un code, toutes les plateformes
Règles HIG par plateforme
Chaque plateforme Apple a ses spécificités que votre Design System doit respecter :
| Plateforme | Particularité | Adaptation requise |
|---|---|---|
iOS | Touch-first, 44pt targets | Boutons larges, swipe gestures |
iPadOS | Pointer support, multitasking | Hover states, sidebars |
macOS | Precision cursor, menus | Boutons plus petits, raccourcis clavier |
watchOS | Écran minimal, glances | Composants compacts, Digital Crown |
tvOS | Focus-based, télécommande | États focus visibles, navigation directionnelle |
visionOS | Spatial, eye-tracking | Profondeur Z, hover effects spatiaux |
“Règle HIG : Un bon Design System ne force pas l'uniformité absolue — il adapte l'expression visuelle au paradigme d'interaction de chaque plateforme tout en maintenant l'identité de marque.”
Tests automatisés du Design System
Gouvernance du Design System
Le triangle Design-Dev-Product
Un Design System réussi nécessite l'alignement de trois parties :
| Rôle | Responsabilité | Livrable |
|---|---|---|
Design | Définir les guidelines visuelles | Figma components, specs |
Dev | Implémenter les composants | Swift Package, tests |
Product | Prioriser et adopter | Roadmap DS, métriques |
Versioning sémantique
Votre Design System doit suivre le Semantic Versioning (SemVer) :
Documentation as Code
Chaque composant doit inclure :
- Description — Ce que fait le composant
- Usage — Exemples de code
- Props/API — Paramètres disponibles
- Variants — États et variations
- Accessibility — Comportement VoiceOver
- HIG Reference — Lien vers la guideline Apple
- Do/Don't — Bonnes et mauvaises pratiques
“Standard industrie : Les Design Systems matures (Shopify Polaris, Atlassian, IBM Carbon) publient une documentation web avec playground interactif. Pour SwiftUI, utilisez DocC + Swift Playgrounds.”
Pour aller plus loin
Documentation officielle Apple
WWDC Sessions essentielles
WWDC 2024 : "Design for visionOS" — Patterns multi-plateforme
WWDC 2023 : "Build accessible apps with SwiftUI" — Accessibilité avancée
WWDC 2023 : "Discover Observation in SwiftUI" — State management moderne
WWDC 2022 : "The SwiftUI cookbook for navigation" — Architecture de navigation
Ressources communautaires
Design+Code — Cours SwiftUI et Design
Mobbin — Inspiration UI/UX mobile
Apple Design Resources — Templates officiels
Un Design System n'est pas un projet ponctuel — c'est un produit vivant qui évolue avec vos besoins. Investir dans cette fondation en 2025 vous fera gagner des mois de développement et garantira une expérience utilisateur cohérente sur toutes les plateformes Apple.
Dans un prochain article, nous verrons comment automatiser la documentation et la validation de votre Design System avec des pipelines CI/CD.