Free Press

L’exécution de pod install installera la version actuelle de RestKit, provoquant la génération d’un Podfile.lock qui indique la version exacte installée (par exemple RestKit 0.10.3). Grâce au Podfile.lock, l’exécution de pod install sur ce projet hypothétique à un moment ultérieur sur une machine différente installera toujours RestKit 0.10.3 même si une version plus récente est disponible. CocoaPods honorera la version du Pod dans Podfile.lock à moins que la dépendance soit mise à jour dans le Podfile ou que pod update soit appelé (ce qui entraînera la génération d’un nouveau Podfile.lock). De cette façon, CocoaPods évite les maux de tête causés par des modifications inattendues des dépendances.

Il y a une excellente vidéo de Google sur la façon dont cela fonctionne : « CocoaPods et Lockfiles (Route 85) ».

<Que se passe-t-il en coulisse ?

Dans Xcode, avec des références directement issues du source ruby, il :

1. Crée ou met à jour un espace de travail.
2. Ajoute votre projet à l’espace de travail si nécessaire.
3. Ajoute le projet de bibliothèque statique CocoaPods à l’espace de travail si nécessaire.
4. Ajoute libPods.a pour : cibles => phases de construction => lier avec les bibliothèques.
5. Ajoute le fichier de configuration CocoaPods Xcode au projet de votre application.
6. Change les configurations des cibles de votre application pour qu’elles soient basées sur celles de CocoaPods.
7. Ajoute une phase de construction pour copier les ressources de tous les pods que vous avez installés dans votre bundle d’app. c’est-à-dire une  » phase de construction de script  » après toutes les autres phases de construction avec les éléments suivants :
   • Shell : /bin/sh
   • Scripts : ${SRCROOT}/Pods/PodsResources.sh

Notez que les étapes 3 et suivantes sont sautées si la bibliothèque statique CocoaPods est déjà dans votre projet. Ceci est largement basé sur le travail de Jonah Williams sur les bibliothèques statiques.

<Pods et submodules

CocoaPods et les submodules git tentent de résoudre des problèmes très similaires. Tous deux s’efforcent de simplifier le processus d’inclusion de code tiers dans votre projet. Les submodules sont liés à un commit spécifique de ce projet, tandis qu’un CocoaPod est lié à une version de développeur versionnée.

<Commutation de submodules à CocoaPods

Avant de décider de faire le passage complet à CocoaPods, assurez-vous que les bibliothèques que vous utilisez actuellement sont toutes disponibles. C’est également une bonne idée d’enregistrer les versions des bibliothèques que vous utilisez actuellement, afin que vous puissiez configurer CocoaPods pour utiliser les mêmes. C’est aussi une bonne idée de faire cela de manière incrémentielle, en allant dépendance par dépendance au lieu d’un grand mouvement.