Xcode se plaint « No such module », alors que le framework est en place : que faire ?

« No such module » : le cauchemar familier de tout développeur Swift

Vous ajoutez un framework via SPM, CocoaPods ou manuellement, vous le voyez dans le Project Navigator, tout semble parfait — mais Xcode écrit obstinément : No such module 'Alamofire' (ou tout autre module). Familier ? Si oui — vous n'êtes pas seul. La question originale sur Stack Overflow a recueilli des dizaines de milliers de vues, et les commentaires sont devenus un véritable recueil de la douleur des développeurs iOS.

Dans cet article, nous allons passer en revue 10 causes réelles pour lesquelles l'erreur No such module se produit, et montrer comment les corriger. À la fin, une liste de contrôle vous attend pour vous faire gagner des heures de stress.

Pourquoi Xcode ne voit-il pas le module ? Top 10 des causes

1. Derived Data — le principal coupable

Xcode met en cache les informations sur le projet dans le dossier Derived Data. Si le cache est obsolète ou corrompu, le compilateur « oublie » les modules connectés. C'est la première chose à vérifier.

Comment corriger :

\n
• Fermez Xcode
\n
• Ouvrez le terminal et exécutez :\n

  rm -rf ~/Library/Developer/Xcode/DerivedData

  \n
\n
• Ou manuellement : Xcode → Preferences → Locations → Derived Data → cliquer sur la flèche → supprimer le dossier
\n
• Redémarrez Xcode et faites Cmd + B
\n

2. Configuration incorrecte de Build Phases

Même si le framework est physiquement présent dans le projet, Xcode peut ne pas savoir qu'il doit le lier. Vérifiez Link Binary With Libraries :

\n
• Sélectionnez la cible (target) → Build Phases
\n
• Dépliez Link Binary With Libraries
\n
• Assurez-vous que votre framework y figure
\n
• Sinon — cliquez sur + et ajoutez-le
\n

3. Swift Package Manager : mauvaise branche ou version

SPM est un outil pratique, mais il est sensible aux versions. Si vous avez spécifié from: "1.0.0" alors que le dépôt contient la version 2.0.0, Xcode peut ne pas trouver de module compatible.

// Exemple de Package.swift\ndependencies: [\n    .package(url: "https://github.com/Alamofire/Alamofire.git", from: "5.6.0")\n]

Que faire :

\n
• Allez dans File → Packages → Update to Latest Package Versions
\n
• Si le problème persiste — supprimez le framework et ajoutez-le à nouveau
\n
• Vérifiez Package Dependencies dans le projet — le module doit être en vert
\n

4. Conflit d'architectures (Architectures)

Les anciens frameworks peuvent être compilés uniquement pour arm64, alors que votre projet inclut le simulateur (x86_64). Avec l'arrivée d'Apple Silicon, c'est devenu une cause fréquente.

Solution : Ajoutez dans Build Settings → Excluded Architectures pour la compilation Debug :

\n
• Pour le simulateur : arm64
\n
• Pour l'appareil : $(ARCHS_STANDARD)
\n

5. Chemin de recherche incorrect (Framework Search Paths)

Si vous ajoutez un framework manuellement, Xcode doit savoir où le trouver. Vérifiez Framework Search Paths :

\n
• Build Settings → Framework Search Paths
\n
• Assurez-vous que le chemin mène au dossier contenant .framework ou .xcframework
\n
• Pour SPM, généralement rien n'est à spécifier, mais pour les frameworks manuels, c'est obligatoire
\n

6. Framework non ajouté à toutes les cibles

Un projet peut avoir plusieurs cibles (application principale, widgets, extensions). Si vous avez ajouté le module à une seule, les autres cibles ne le verront pas.

Vérification : Sélectionnez le framework dans le Project Navigator → inspecteur à droite → Target Membership — cochez toutes les cibles nécessaires.

7. Problèmes avec CocoaPods (si vous l'utilisez)

CocoaPods est un classique, mais parfois après pod install, le framework n'est pas pris en compte.