dyld: Library not loaded: @rpath/libswiftCore.dylib : comment vaincre l'erreur

« Et pouf — l'application a planté » : découvrons dyld: Library not loaded: @rpath/libswiftCore.dylib

Avez-vous déjà lancé votre application Swift, vu un bel écran de démarrage, puis — boum ! — un écran noir et une console pleine de lettres rouges ? Familier ? Si vous avez déjà rencontré le message dyld: Library not loaded: @rpath/libswiftCore.dylib, vous connaissez cette sensation de légère panique. Sur Stack Overflow, cette question a recueilli des milliers de vues, et ce n'est pas pour rien : l'erreur est sournoise, mais tout à fait résoluble.

Dans cet article, nous ne donnerons pas simplement une instruction sèche. Nous allons comprendre pourquoi les bibliothèques Swift « se perdent » à l'exécution, comment l'éviter et que faire si vous êtes déjà dans le pétrin. C'est parti !

Qu'est-ce que dyld et pourquoi se fâche-t-il ?

dyld (dynamic link editor) est le chargeur de bibliothèques dynamiques sur macOS et iOS. Lorsque votre application se lance, dyld recherche toutes les bibliothèques nécessaires aux chemins indiqués dans le binaire. L'un de ces chemins est @rpath (runtime search path). Si la bibliothèque (par exemple, libswiftCore.dylib) n'est pas trouvée à ce chemin, dyld plante avec une erreur.

En termes simples : vous avez dit à l'application « prends le livre sur l'étagère @rpath », mais l'étagère était vide. Tout le mystère est là.

Pourquoi cela se produit-il spécifiquement avec libswiftCore.dylib ?

libswiftCore.dylib est le cœur du runtime Swift. Sans lui, aucun code Swift ne fonctionne. L'erreur survient le plus souvent dans trois cas :

\n
• Vous utilisez Xcode 14+ et le projet est configuré pour une ancienne version de Swift.
\n
• Vous connectez des frameworks ou CocoaPods qui nécessitent une version spécifique du runtime Swift.
\n
• Vous avez oublié d'activer « Always Embed Swift Standard Libraries » dans les paramètres de build.
\n

5 façons de corriger dyld: Library not loaded: @rpath/libswiftCore.dylib

Passons à la pratique. Voici des méthodes éprouvées, de la plus simple à la plus complexe. Pour chacune, je fournirai un exemple de code ou de paramètres.

1. Activez « Always Embed Swift Standard Libraries »

Le coupable le plus fréquent. Si votre application n'intègre pas les bibliothèques Swift dans le bundle, dyld ne les trouvera pas sur l'appareil.

Comment corriger :

\n
1. Ouvrez votre projet dans Xcode.
\n
2. Sélectionnez Target → Build Settings.
\n
3. Recherchez Always Embed Swift Standard Libraries.
\n
4. Définissez la valeur sur Yes.
\n

Si vous utilisez CocoaPods, vérifiez qu'il n'y a pas de ligne dans le Podfile désactivant ce comportement :

# Mauvais (peut provoquer l'erreur)\npost_install do |installer|\n  installer.pods_project.targets.each do |target|\n    target.build_configurations.each do |config|\n      config.build_settings['ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES'] = 'NO'\n    end\n  end\nend\n\n# Bon\npost_install do |installer|\n  installer.pods_project.targets.each do |target|\n    target.build_configurations.each do |config|\n      config.build_settings['ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES'] = 'YES'\n    end\n  end\nend\n

2. Vérifiez la compatibilité des versions Swift

Si vous avez connecté un framework compilé avec Swift 5.7, alors que votre projet est en Swift 5.5 — bonjour l'erreur. Le runtime Swift n'est pas rétrocompatible à « 100 % ».

Solution : assurez-vous que toutes les dépendances utilisent la même version de Swift. Ouvrez le terminal et exécutez :

# Connaître la version Swift pour un .framework spécifique\nstrings MyFramework.framework/MyFramework | grep "Swift"\n# Ou vérifiez via xcrun\nxcrun swift --version\n

Si le framework est compilé avec une version différente — recompilez-le ou mettez-le à jour.

3. Nettoyez Derived Data et reconstruisez le projet

Parfois, Xcode met en cache d'anciens chemins vers les bibliothèques. Une reconstruction complète résout souvent le problème.

# Supprimer Derived Data manuellement\nrm -rf ~/Library/Developer/Xcode/DerivedData