Introduction à la gestion de la dépendance dans iOS

Le développement moderne d'iOS commence rarement à zéro. Les bibliothèques tierces gèrent tout, du réseautage et de l'analyse JSON aux composants d'interface utilisateur et à la mise en cache d'images. Sans approche structurée, le téléchargement manuel des cadres, la résolution des conflits de versions et la liaison des binaires deviennent rapidement un cauchemar de maintenance.

CocoaPods et Carthage sont les deux outils les plus établis pour gérer les dépendances dans les projets iOS. Alors que CocoaPods offre une intégration simplifiée et basée sur l'espace de travail, Carthage suit une philosophie décentralisée, build-it- yourself. Comprendre les forces et les compromis de chacun vous aide à choisir la bonne approche pour votre équipe, votre application, et votre pipeline de déploiement.

Pods de cacao: centralisés et automatisés

CocoaPods est le gestionnaire de dépendances dominant depuis son introduction. Il utilise un index central appelé CocoaPods Specs et génère un espace de travail Xcode qui gère toutes les dépendances automatiquement. Cela signifie que vous pouvez ajouter une bibliothèque en la déclarant simplement dans un fichier Pod, en exécutant une commande et en l'important immédiatement dans votre code.

Installation et configuration

CocoaPods est installé via RubyGems. macOS est livré avec Ruby, mais vous devrez peut-être mettre à jour ou utiliser un gestionnaire de version Ruby. La commande d'installation standard est:

sudo gem install cocoapods

Après l'installation, naviguez dans votre répertoire de projet et initialisez un fichier Pod:

pod init

Vous l'éditez ensuite pour spécifier votre plateforme cible, tout drapeau (requis pour les bibliothèques Swift) et les dépendances dont vous avez besoin. Un fichier Pod typique ressemble à ceci :

platform :ios, '15.0'

target 'MyApp' do
 use_frameworks!

 pod 'Alamofire', '~> 5.7'
 pod 'SwiftyJSON', '~> 5.0'
 pod 'SDWebImage', '~> 5.15'
end

Une fois le fichier Pod est prêt, lancez :

pod install

CocoaPods télécharge les versions spécifiées, résout les dépendances et génère un fichier . A partir de ce moment, vous devez ouvrir l'espace de travail — pas l'original — pour construire et exécuter votre application.

Caractéristiques avancées de CocoaPods

  • Subspecs:[ De nombreuses bibliothèques vous permettent d'importer seulement un sous-ensemble de leurs fonctionnalités. Par exemple, réduit l'empreinte binaire.
  • Pistes locales: Vous pouvez pointer vers un dossier local pour les bibliothèques privées:
  • Sources basées sur le git:[ Les dépendances peuvent provenir de n'importe quel dépôt Git:
  • Podfile.lock:[ Ce fichier verrouille chaque dépendance à une version spécifique, assurant des constructions reproductibles à travers votre équipe et CI.
  • Plugins: Vous pouvez étendre CocoaPods avec des plugins pour SwiftLint, Firebase ou des scripts de construction personnalisés.

CocoaPods prend également en charge des cibles multiplateformes. Vous pouvez avoir différents ensembles de dépendance pour iOS, macOS et watchOS en nichant des blocs dans un seul fichier Pod.

Crochets post-Installation et personnalisation

Un besoin commun est d'exécuter un script après chaque . Par exemple, vous pouvez vouloir retirer les architectures de simulateur de constructions de libération. Ceci est fait avec un crochet:

post_install do |installer|
 installer.pods_project.targets.each do |target|
 target.build_configurations.each do |config|
 config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '15.0'
 end
 end
end

Ces crochets vous donnent un contrôle fin sur le projet Pods généré, mais ils ajoutent aussi de la complexité. Overuse peut rendre votre fichier Pod difficile à lire et à maintenir.

Carthage: Décentralisation et main-off

Carthage adopte une approche différente. Au lieu de centraliser les métadonnées, il s'appuie sur les balises Git et les projets Xcode réels de chaque bibliothèque. Carthage construit les cadres sur votre machine et laisse à votre choix l'étape d'intégration – les cadres draguants dans votre projet Xcode. Cette interférence minimale attire les développeurs qui veulent un contrôle total et une empreinte plus petite dans leur contrôle de version.

Installation et configuration

Carthage est généralement installé via Homebrew:

brew install carthage

Ensuite, créez un fichier texte simple nommé Cartfile dans votre racine de projet. La syntaxe est similaire à CocoaPods mais pointe vers les dépôts GitHub ou toute source Git:

github "Alamofire/Alamofire" ~> 5.7
github "SwiftyJSON/SwiftyJSON" ~> 5.0
github "onevcat/Kingfisher" ~> 7.0

Après avoir édité le fichier Cartfile, lancez :

carthage update --platform iOS

Cette commande clone les dépôts, vérifie les versions marquées et construit les cadres en utilisant Xcode. Les binaires résultants sont placés dans le dossier Carthage/Build/iOS. Vous les faites glisser manuellement dans votre projet Xcode sous la section «Frameworks, Libraries, and Embedded Content», en veillant à les ajouter à la cible appropriée.

Différences clés par rapport aux Pois de Cacao

  • Aucun espace de travail: Carthage ne modifie pas votre fichier de projet. Vous restez en contrôle des références de fichier et créez des paramètres.
  • Vitesse de construction: Carthage peut créer des caches. Sur CI, vous pouvez préconstruire des dépendances pour accélérer le pipeline.
  • Versionnement: Carthage utilise un Cartfile.resolved pour verrouiller des versions, semblables à Podfile.lock.
  • Binary frameworks: Certaines bibliothèques expédient des binaires . Carthage peut les télécharger directement, sauter l'étape de construction et gagner du temps.
  • XCFramework support:[ Depuis Carthage 0.38, il peut sortir XCFrameworks, qui fonctionne en toute transparence avec Swift Package Manager et élimine le besoin de dégraisser les architectures de simulateur.

Manipulation des cadres avec dépendances

Si la bibliothèque A dépend de la bibliothèque B, vous devez énumérer les deux dans le fichier Cartfile. Carthage résout automatiquement l'arborescence de dépendance, mais vous devez toujours lier manuellement toutes les dépendances transitoires de votre projet. Cela vous donne une visibilité dans chaque binaire contre les liens de votre application, mais cela augmente également les chances de manquer un cadre requis à l'exécution.

Comparaison des Pois de Cacao et Carthage: un guide pratique

Le choix entre les deux dépend de la taille de votre projet, de la maturité de l'équipe et du flux de travail de déploiement. Le tableau ci-dessous résume les compromis clés.

Factor CocoaPods Carthage
Setup complexity Low – one command, workspace generated automatically. Medium – requires manual linking of frameworks.
Build system control Lower – CocoaPods merges project files and may override build settings. Higher – you control project structure and build phases.
Integration with Xcode Tight – workspace includes Pods project, all configurations preset. Loose – you add frameworks manually; no workspace changes.
CI/CD compatibility Good – pod install works reliably in CI, but full rebuild on each run if lockfile changes. Excellent – prebuilt frameworks can be cached; build times are faster.
Swift Package Manager migration Can coexist but may cause conflicts if both manage the same library. Can coexist more easily because Carthage does not modify project files.
Community and library availability Widest coverage – almost every popular library has a CocoaPods spec. Good coverage – but some niche libraries may not be Carthage-friendly.

Quand utiliser des Pois de Cacao

  • Vous commencez un nouveau projet et voulez une plaque de chaudière minimale.
  • Votre équipe comprend des développeurs juniors qui bénéficient d'une intégration pratique.
  • Vous avez besoin d'une bibliothèque qui n'est disponible que via CocoaPods (il arrive toujours pour certains pods legs ou propriétaires).
  • Vous comptez fortement sur les plugins CocoaPods (par exemple pour les vérifications de lint ou la génération de code).

Quand utiliser Carthage

  • Vous appréciez la modularité et voulez éviter le bloat "Projet de Pods".
  • Votre application est grande, et vous devez optimiser les temps de construction en cachant les cadres préconstruits.
  • Vous migrez vers Swift Package Manager et souhaitez une transition progressive sans casser les intégrations existantes.
  • Vous travaillez sur une équipe qui préfère garder le projet Xcode maigre et gérer manuellement les paramètres de construction.

Migration entre gestionnaires de la dépendance

Passer de CocoaPods à Carthage ou vice versa est possible mais nécessite une planification minutieuse. Voici les étapes de haut niveau.

Migrer de CocaaPods à Carthage

  1. Enlever le fichier Pod, Podfile.lock et l'espace de travail.
  2. Supprimer toute phase de construction liée aux pods (par exemple, --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  3. Créer un fichier Cart et lister les mêmes bibliothèques (en assurant qu'elles prennent en charge Carthage).
  4. Exécuter .
  5. Ajouter manuellement chaque cadre de Carthage/Build/iOS au projet Xcode.
  6. Mettre à jour tous les énoncés d'importation – sous Carthage, vous importez des cadres directement (p. ex. ).
  7. Testez soigneusement; les dépendances transitoires peuvent maintenant nécessiter des liens explicites.

Migrant de Carthage à CocoaPods

  1. Supprimer les phases de construction et les références de cadre liées à Carthage du projet Xcode.
  2. Supprimer le fichier Cartfile et Cartfile.resolved.
  3. Exécutez pour créer un fichier Pod.
  4. Ajoutez toutes les dépendances avec les contraintes de version appropriées.
  5. Exécutez et ouvrez le nouvel espace de travail.
  6. Vérifier les importations de duplicata – CocoaPods peut intégrer des bibliothèques différemment.
  7. Mettre à jour les paramètres de construction si nécessaire (p. ex. ].

Meilleures pratiques pour les deux gestionnaires

Quel que soit l'outil que vous choisissez, suivre ces pratiques permettra de maintenir votre projet en bonne santé.

  • Commander les fichiers de verrouillage: Toujours engager Podfile.lock ou Cartfile.résolu au contrôle de la version. Cela garantit que chaque membre de l'équipe et serveur CI utilise exactement les mêmes versions.
  • Versions de pin soigneusement:[ Utilisez des opérateurs optimistes ([) pour permettre des mises à jour mineures tout en bloquant les changements majeurs de rupture.
  • Run updates délibérément:[ Ne pas exécuter ou sans revoir les changements de dépendances mises à jour.
  • Audit pour la compatibilité de la version Swift: Certaines bibliothèques peuvent ne pas supporter la version Swift de votre projet. Vérifiez que la dépendance de la branche ou de la balise correspond à votre chaîne d'outils Swift.
  • Supprimer les dépendances inutilisées:[ Examinez périodiquement votre fichier Cartfile ou Podfile et supprimez les bibliothèques qui ne sont plus utilisées.
  • Consider SPM pour de nouveaux projets: Swift Package Manager est maintenant intégré dans Xcode et supporté par la plupart des bibliothèques majeures. Si vous commencez à zéro, SPM peut être le choix le plus simple. CocoaPods et Carthage restent excellents pour gérer de grands projets ou cadres privés.

Dépannage de problèmes communs

Pods de cacao: -Spécification non trouvée

Cela signifie généralement que la bibliothèque n'a pas été poussée vers le coffre de CocoaPods ou que vous utilisez un nom erroné. Vérifiez le nom de la pod sur cocoapods.org. Si la bibliothèque est privée, vous devez spécifier sa source dans votre fichier Pod.

Pods de cacao: Conflits dans les dépendances transitoires

Exécutez et inspectez la sortie. Vous devrez peut-être ajouter des contraintes de version explicites pour les pods transitoires. L'utilisation de et d'un nouveau peut réinitialiser le graphique de dépendance.

Carthage: - Pas de module de ce type lors de la construction

Souvent, cela se produit parce que le framework n'a pas été construit pour la plate-forme correcte (par exemple, vous avez construit avec par erreur). Re-exécuter et vérifier le dossier de sortie. Assurez-vous également que vous avez ajouté le framework à la section -Frameworks, Libraries et Contenu Embedded, et pas seulement au navigateur du projet.

Carthage: La construction échoue en raison de dépendances manquantes

Si une bibliothèque que vous utilisez a ses propres dépendances (comme les dépendances RxSwift), vous devez les lister dans votre fichier Cartfile. Carthage ne télécharge pas automatiquement les dépendances transitoires à moins qu'elles n'apparaissent dans le fichier Cartfile ou soient spécifiées comme sous-modules.

Approches hybrides : Utilisation des CocoaPods et Carthage

Bien que le mélange des gestionnaires de dépendance dans un projet ne soit pas recommandé, certaines équipes le font par nécessité. Par exemple, une bibliothèque critique peut être disponible uniquement via CocoaPods, tandis que le reste du projet utilise Carthage. Si vous devez les combiner, gardez l'espace de travail CocoaPods séparé et liez manuellement les cadres de Carthage. Soyez conscient des conflits potentiels dans les symboles dupliqués ou les ressources qui se chevauchent.

L'avenir de la gestion de la dépendance iOS

Swift Package Manager (SPM) est désormais considéré comme la norme par Apple et est intégré directement dans Xcode 11 et plus tard. La plupart des bibliothèques open-source ont ajouté le support SPM, et SPM élimine le besoin d'outils externes.

  • CocoaPods offre une riche personnalisation à travers des crochets et des plugins, et son dépôt de spécifications reste la plus grande collection de bibliothèques iOS.
  • Carthage vous donne un contrôle complet sur le processus de construction et est plus facile à mettre en cache, ce qui le rend populaire dans les flux de travail lourds de CI.

De nombreuses équipes utilisent SPM pour de nouvelles dépendances tout en maintenant les intégrations héritées avec CocoaPods ou Carthage. Au fil du temps, SPM est censé devenir la valeur par défaut, mais pour l'instant, comprendre les trois outils vous permet de travailler sur n'importe quelle base de code iOS.

Conclusion

Une gestion efficace de la dépendance est la pierre angulaire du développement professionnel iOS. CocoaPods fournit une solution clé en main qui automatise l'ensemble du processus d'intégration, ce qui le rend idéal pour les équipes qui veulent la vitesse et la simplicité. Carthage offre une approche plus fine et plus transparente qui donne aux développeurs un contrôle granulaire sur les systèmes de construction et la structure du projet. En maîtrisant les deux outils, vous pouvez choisir la bonne adaptation pour votre projet, la taille, la complexité et le flux de travail.

Pour plus de détails, explorez les guides officiels de CocoaPods et le dépôt Carthage GitHub.