Fiche 03.11 — Dark mode propre
Objectif
Comprendre comment faire en sorte qu’une app SwiftUI s’adapte correctement au mode clair et au mode sombre, sans repeindre toutes les couleurs à la main et sans casser la lisibilité dans un des deux modes.
1. L’idée à comprendre
iOS propose deux apparences :
- Light mode (clair)
- Dark mode (sombre)
L’utilisateur choisit lui-même dans les Réglages → Luminosité et affichage. Une app pro doit gérer les deux sans rien à faire dans le code dans 90 % des cas, à condition d’utiliser les bonnes couleurs.
Le piège classique : utiliser des couleurs codées en dur (Color.white, Color.black, Color(red: ...)) qui restent identiques dans les deux modes et rendent l’app illisible.
La solution : utiliser des couleurs adaptatives.
2. Les couleurs système adaptatives
SwiftUI fournit des couleurs qui s’adaptent automatiquement au mode courant.
Couleurs sémantiques de texte
Couleurs de fond UIKit (toujours valables)
Exemple :
Cet écran sera lisible en clair et en sombre sans rien faire de plus.
3. Couleurs personnalisées via Assets
Pour ta couleur de marque (ex. un orange spécifique), utilise un asset couleur.
Dans Assets.xcassets :
Puis dans le code :
Tu peux ainsi définir une variante différente pour le dark mode, plus lisible sur fond sombre.
4. Centraliser dans un design system
Combine avec la fiche 03.06 (design system) :
Tu n’as plus jamais à te poser la question "ça marche en dark ?". Toutes les vues utilisent ces tokens.
5. Détecter le mode courant avec @Environment
Parfois tu veux adapter une image ou un comportement selon le mode.
colorScheme peut valoir .light ou .dark.
Astuce : pour les images, tu peux aussi créer un asset image avec deux variantes (Any Appearance + Dark Appearance) et l’utiliser comme une couleur :
C’est plus propre que le if dans le code.
6. Forcer un mode sur une vue
Tu peux forcer une vue spécifique en clair ou en sombre.
Cas d’usage : un écran de splash ou de vidéo qui doit toujours être sombre. Ne fais pas ça sur toute l’app sauf raison forte (l’utilisateur a choisi son mode dans les Réglages).
7. Tester en preview dans les deux modes
C’est la première chose à faire avant de livrer un écran : vérifier visuellement les deux modes.
8. Erreurs fréquentes
Couleurs codées en dur
Pas bien :
→ invisible en dark mode.
Mieux :
Couleurs custom non adaptées
→ presque invisible en mode sombre.
Mieux : passer par un asset couleur avec deux variantes.
Images non adaptées
Un logo noir codé en dur reste noir sur fond noir. Soit utilise .foregroundStyle(.primary) pour une icône SF Symbol, soit fournis deux variantes de l’image dans les assets.
Ombres trop fortes en dark mode
Les ombres .shadow(radius: 10) sont parfois moches en dark mode. Pense à les réduire ou à les supprimer :
9. Exemple complet d’écran dark-mode ready
Cet écran fonctionne dans les deux modes sans if colorScheme.
10. Points à connaître
Le dark mode n’est pas optionnel
Beaucoup d’utilisateurs sont en dark mode 24/7. Une app qui casse en sombre paraît amateur.
Les couleurs système font 90 % du travail
Si tu utilises Color.primary, Color.secondary, Color(.systemBackground), tu n’as quasiment rien à faire.
Les assets couleur, c’est pour ta marque
Tout ce qui n’est pas système (orange de marque, vert de validation custom) doit passer par un asset avec deux variantes.
Toujours preview les deux modes
Cette habitude évite 100 % des bugs visuels en dark mode.
Résumé
À retenir :
- iOS propose
lightetdark, les utilisateurs choisissent dans les Réglages ; - ne jamais utiliser
.white,.black, ou desColor(red:green:blue:)codés en dur pour du texte ou des fonds ; - préfère
Color.primary,Color.secondary,Color(.systemBackground),Color(.secondarySystemBackground); - pour les couleurs de marque, crée des assets couleur avec une variante Dark Appearance ;
@Environment(\.colorScheme)permet de détecter le mode dans le code si besoin ;.preferredColorScheme(.dark)force un mode mais à utiliser avec parcimonie ;- preview chaque écran en light et en dark avant de livrer ;
- attention aux images et aux ombres qui peuvent mal passer en sombre.