Architecture & modularisation Swift
Publié le · Mis à jour le · 5 min
Votre codebase Swift a besoin de structure ? Je vous accompagne sur l'architecture et la modularisation :
Audit d'architecture — analyse de votre code actuel, identification des points de friction
Plan de modularisation — stratégie de découpage en modules Swift Package Manager
Migration progressive — accompagnement sur la refonte sans tout casser
Architecture from scratch — mise en place d'une structure saine dès le départ
Définition de patterns — choix et implémentation d'un pattern adapté (MVVM, TCA, Clean...)
“Ce service porte sur la structure. Je vous aide à concevoir et mettre en œuvre l'architecture — pas à développer vos features.”
Pourquoi investir dans l'architecture ?
Un projet bien structuré n'est pas un luxe — c'est un investissement qui se rentabilise rapidement :
| Problème courant | Symptômes | Impact |
|---|---|---|
Monolithe | Temps de build explosifs, merge conflicts permanents | Productivité équipe divisée par 2-3x |
Pas de séparation | Tests impossibles, bugs en cascade | Coût de maintenance x5 |
Dépendances circulaires | Impossible de réutiliser du code | Duplication, dette technique |
Pas de conventions | Chaque dev fait différemment | Onboarding lent, reviews interminables |
“Une bonne architecture ne ralentit pas le développement — elle l'accélère sur le long terme.”
Patterns d'architecture
MVVM (Model-View-ViewModel)
Le pattern le plus répandu sur iOS. Simple à comprendre, compatible SwiftUI et UIKit.
| Avantages | Inconvénients |
|---|---|
Simple et bien documenté | Peut devenir "Massive ViewModel" |
Parfait pour SwiftUI | Navigation parfois floue |
Testable (ViewModel isolé) | Pas de gestion d'état globale |
Idéal pour : Apps de taille moyenne, équipes débutantes en archi, projets SwiftUI-first.
TCA (The Composable Architecture)
Framework de Point-Free. Unidirectionnel, composable, très testable.
| Avantages | Inconvénients |
|---|---|
État global prévisible | Courbe d'apprentissage |
Composable par design | Verbosité (Reducer, Action, State...) |
Tests déterministes | Dépendance à un framework |
Idéal pour : Apps complexes avec beaucoup d'état, équipes expérimentées, projets long terme.
Clean Architecture
Séparation stricte en couches concentriques (Entities, Use Cases, Interface Adapters, Frameworks).
| Avantages | Inconvénients |
|---|---|
Indépendance des couches | Setup initial conséquent |
Testabilité maximale | Over-engineering si mal dosé |
Adapté aux grandes équipes | Beaucoup de boilerplate |
Idéal pour : Projets enterprise, équipes multiples, exigences de maintenabilité strictes.
Micro-features
Découpage par feature dans des modules SPM indépendants. Chaque feature = 1 package.
| Avantages | Inconvénients |
|---|---|
Build incrémentaux rapides | Nécessite discipline |
Isolation forte | Complexité du graphe de dépendances |
Réutilisation facile | Tooling SPM encore limité |
Idéal pour : Monorepos, équipes feature-teams, apps modulaires.
Modularisation avec SPM
Swift Package Manager est devenu le standard pour la modularisation. Voici une structure type :
Bénéfices de la modularisation
| Métrique | Avant modularisation | Après modularisation |
|---|---|---|
Temps de build clean | 5-10 min | 1-2 min |
Temps de build incrémental | 30-60 sec | 5-10 sec |
Conflits de merge | Quotidiens | Rares |
Couverture de tests | < 30% |
|
Onboarding nouveau dev | 2-3 semaines | 3-5 jours |
Types d'intervention
Audit d'architecture
Analyse complète de votre codebase :
Cartographie des dépendances
Identification des anti-patterns
Mesure de la dette technique
Recommandations priorisées
Durée : 2-5 jours selon la taille du projet Livrable : Document d'audit + présentation des findings
Plan de modularisation
Stratégie de découpage adaptée à votre contexte :
Définition des modules cibles
Graphe de dépendances
Ordre de migration
Estimation de l'effort
Durée : 3-5 jours Livrable : Plan de modularisation + roadmap
Accompagnement migration
Je travaille avec votre équipe pour migrer progressivement :
Extraction des premiers modules
Mise en place des conventions
Formation de l'équipe
Reviews et ajustements
Durée : 1-3 mois Format : Temps partiel ou full-time selon urgence
Architecture from scratch
Nouveau projet ? Partons sur de bonnes bases :
Choix du pattern adapté
Structure de projet SPM
Conventions de code
Setup CI/CD
Documentation ADR
Durée : 1-2 semaines Livrable : Projet bootstrappé + documentation
Principes SOLID en Swift
Au-delà des patterns, les fondamentaux restent essentiels :
| Principe | Application Swift |
|---|---|
S - Single Responsibility | Un ViewModel = une responsabilité. Un module = un domaine. |
O - Open/Closed | Extensions et protocols plutôt que modification de code existant. |
L - Liskov Substitution | Protocols bien définis, pas de sous-types qui cassent les contrats. |
I - Interface Segregation | Petits protocols ciblés plutôt qu'un gros protocol fourre-tout. |
D - Dependency Inversion | Injection de dépendances, pas d'instanciation en dur. |
Pour qui ?
Ce service s'adresse aux équipes qui :
Souffrent de temps de build trop longs — monolithe à découper
Préparent une refonte — besoin d'une vision claire avant de coder
Veulent scaler — passer de 2 à 10 devs sans chaos
Lancent un nouveau projet — partir sur de bonnes bases
Modernisent un legacy — migration UIKit → SwiftUI, Swift 4 → Swift 6
Exemple de transformation
| Aspect | Avant | Après |
|---|---|---|
Structure | 1 target monolithique (150k lignes) | 12 modules SPM |
Build time | 8 min (clean), 45 sec (incrémental) | 2 min (clean), 8 sec (incrémental) |
Tests | 2000 tests, 40% flaky | 2500 tests, < 1% flaky |
Équipe | 6 devs, merge hell quotidien | 6 devs, 3 feature teams autonomes |
Onboarding | 3 semaines avant productivité | 1 semaine |
À ne pas confondre avec...
- Pas du développement d'app → voir Applications Apple
- Pas de l'optimisation perf → voir Performance & mémoire
- Pas du conseil seul → voir Accompagnement technique
Ici, on structure. Vous repartez avec un plan d'architecture et/ou un codebase restructuré.
Questions fréquentes
"On peut modulariser sans tout casser ?"
Oui. La migration se fait module par module, en production. Pas besoin de feature freeze. On extrait les couches basses d'abord (Core, Shared), puis les features une par une.
"SPM ou Tuist ?"
SPM natif pour la plupart des projets. Tuist si vous avez besoin de génération de projets complexe ou de features avancées (caching, graphs). Je vous conseille selon votre contexte.
"Quel pattern choisir ?"
Ça dépend. MVVM pour la simplicité, TCA pour la rigueur, Clean pour l'enterprise. On définit ça ensemble lors du cadrage.
"Tu codes ou tu conseilles ?"
Selon le format. Audit et plan = conseil. Migration = je code avec votre équipe. From scratch = je livre un projet bootstrappé.