Ce guide concerne les développeurs indépendants qui créent une application native iOS ou macOS et doivent choisir leur méthode de gestion des dépendances.

Il s’adresse aussi aux petites équipes qui entretiennent une application reposant sur CocoaPods, des composants privés ou des SDK binaires, puis doivent la reconstruire de manière fiable sur un Mac distant ou dans une chaîne d’intégration continue.

La documentation d’Apple confirme l’intégration des paquets Swift dans Xcode, tandis que la documentation officielle de Swift décrit la résolution des dépendances et le fichier Package.resolved dans le guide Swift Package Manager. Cela établit une capacité technique, pas une obligation de migrer tous les projets existants.

Un outil intégré plus profondément à Xcode ne supprime pas les contraintes de licence, d’authentification, de ressources ou de scripts. Votre choix doit suivre le contenu réel du dépôt.

Pour un projet iOS ou macOS créé aujourd’hui, Swift Package Manager mérite d’être évalué en premier lorsque les dépendances critiques proposent une intégration officielle et complète. Vous restez alors dans le modèle de projet géré par Xcode, sans ajouter automatiquement toute la chaîne Ruby et les fichiers de génération associés à CocoaPods.

Le bénéfice principal n’est pas seulement la simplicité de l’installation. Il concerne la restauration du projet. Le manifeste du paquet décrit les dépendances, et Package.resolved conserve les versions résolues lorsque ce fichier est correctement suivi dans le dépôt selon le type de projet et la politique retenue. La documentation d’Apple présente la gestion des Swift packages dans Xcode, notamment leur ajout au projet et leur résolution.

Ce que vous devez vérifier avant de choisir

Ne concluez pas qu’une bibliothèque est compatible parce qu’elle est écrite en Swift. Demandez au fournisseur si le paquet prend réellement en charge :

• la version de Swift et de Xcode utilisée par votre équipe ;
• les produits à importer dans chaque Target ;
• les ressources, catalogues d’images, fichiers audio ou modèles nécessaires ;
• les cibles binaires, le cas échéant ;
• iOS, macOS, simulateur et appareil physique selon votre matrice de publication ;
• les scripts complémentaires exigés après l’installation ;
• l’authentification nécessaire pour télécharger une dépendance privée.

Cette vérification est particulièrement importante pour les applications créatives. Un projet de montage audio peut dépendre de codecs et de fichiers de ressources. Une application vidéo peut utiliser un SDK binaire avec plusieurs architectures. Un outil de design peut embarquer des polices, des modèles ou des fichiers de démonstration. La présence d’un dépôt Swift ne garantit pas que tous ces éléments sont livrés correctement.

Une organisation adaptée au travail à distance

Swift Package Manager peut réduire le nombre d’étapes spécifiques à l’installation, mais il ne rend pas automatiquement votre projet reproductible. Vous devez encore versionner les fichiers pertinents, documenter les accès privés et séparer le cache de la source de vérité.

Dans une chaîne CI, un cache accélère une restauration déjà correcte ; il ne doit pas être la seule raison pour laquelle la compilation fonctionne. Apple décrit la configuration des dépendances dans les flux d’intégration continue. Utilisez cette référence pour vérifier votre méthode, puis testez-la sur une machine sans cache.

La migration d’un projet CocoaPods vers Swift Package Manager peut être pertinente, mais elle n’est pas automatiquement rentable. Un projet ancien contient souvent davantage que des lignes dans un Podfile : il peut inclure un Podfile.lock, un Workspace, des scripts de post-installation, des réglages de build personnalisés et plusieurs Target.

Si l’application doit être publiée rapidement, la stabilité de cette chaîne a une valeur concrète. Une migration peut modifier les chemins de recherche, les phases de build, l’intégration des ressources ou l’ordre de génération. Même si la résolution des dépendances réussit, l’Archive peut ensuite échouer.

Les conditions raisonnables pour rester sur CocoaPods

Conservez temporairement cette solution si l’une des situations suivantes s’applique :

• une dépendance critique est publiée uniquement comme Pod ;
• un SDK possède des instructions CocoaPods précises pour ses ressources ou ses scripts ;
• plusieurs Target partagent une configuration personnalisée déjà validée ;
• le projet dépend d’un dépôt privé dont l’accès est documenté uniquement pour CocoaPods ;
• une publication urgente est en cours et la migration n’a pas encore de fenêtre de validation ;
• le pipeline actuel restaure le Podfile.lock, installe les dépendances et produit une Archive reproductible.

Le guide officiel d’installation et d’utilisation de CocoaPods documente le fonctionnement de cette chaîne. La commande pod install et la commande pod update n’ont pas le même effet sur les versions résolues ; cette distinction est expliquée dans la documentation officielle correspondante. Dans un dépôt de production, exécuter une mise à jour globale sans examiner le fichier de verrouillage peut donc élargir inutilement le périmètre du changement.

Attention : une installation réussie ne prouve pas que votre projet est prêt à publier. Il faut encore compiler chaque configuration utile, exécuter les tests, produire une Archive et vérifier la signature.

Quand la migration devient-elle défendable ?

Elle devient plus raisonnable lorsque les dépendances principales disposent d’un paquet officiel, que les scripts CocoaPods ne modifient pas fortement le projet et que vous pouvez consacrer une branche de validation à l’opération.

Ne migrez pas plusieurs éléments à la fois sans journal de changement. Si une erreur apparaît, vous devez savoir quel composant a modifié le résultat. L’objectif n’est pas de remplacer un fichier par un autre, mais de préserver le comportement de l’application et du processus de distribution.

Le mode de livraison compte davantage que le langage utilisé par la bibliothèque. Une dépendance privée sous forme de code source, un composant interne et un XCFramework ne présentent pas les mêmes exigences.

CocoaPods propose notamment un mécanisme de Spec Repo privé pour distribuer des composants internes ; consultez la procédure officielle pour les Pods privés avant d’en déduire qu’un simple dépôt Git suffit.

Pour un SDK binaire, vérifiez séparément quatre résultats : téléchargement autorisé, fichier complet, intégration dans le Target et exécution sur les destinations prévues. « Compatible Swift Package Manager » peut signifier que le fournisseur publie un manifeste minimal ; cela ne garantit pas que votre configuration de signature, vos ressources et vos architectures sont couvertes.

Ce tableau ne classe pas les outils par popularité. Il met en évidence les endroits où une validation est nécessaire.

Oui, un projet peut fonctionner temporairement avec CocoaPods et Swift Package Manager. Cette coexistence n’est toutefois pas une stratégie durable par défaut. Elle sert à isoler le risque, à remplacer progressivement les composants et à conserver une voie de retour.

Le danger principal est le doublon. Si une même bibliothèque est ajoutée comme Pod et comme paquet Swift, vous pouvez obtenir des symboles en double, des versions divergentes ou des ressources copiées plusieurs fois. Les dépendances transitives rendent ce problème moins visible : votre projet peut ne déclarer qu’un seul composant, alors que deux chaînes l’introduisent indirectement.

Première étape : cartographier le dépôt

Avant toute modification, établissez une liste de toutes les dépendances et de tous les points d’intégration :

• présence de Podfile, Podfile.lock, Workspace et fichiers de configuration ;
• paquets déjà ajoutés dans Xcode ;
• dépendances transitives importantes ;
• scripts de préparation, de génération ou de copie ;
• ressources livrées par chaque composant ;
• accès privés et variables présentes dans la CI ;
• Target iOS, extensions, tests, widgets et outils macOS.

Ne supprimez pas CocoaPods avant d’avoir identifié les extensions et les Target secondaires. C’est souvent là que la migration devient incomplète.

Deuxième étape : commencer par les composants périphériques

Choisissez ensuite un composant peu risqué. Évitez de commencer par le SDK qui touche l’authentification, le paiement, la vidéo ou la signature. Un composant périphérique permet de vérifier le mode d’importation, les ressources, les tests et l’Archive sans mettre immédiatement en jeu toute la publication.

Pour chaque lot, conservez un changement isolé et un résultat attendu. La résolution doit être distinguée de la compilation : un paquet peut être téléchargé puis refuser de compiler avec votre version de Swift.

Troisième étape : tester le retour arrière

Un lot n’est pas terminé lorsque la nouvelle configuration fonctionne une fois. Vérifiez que vous pouvez revenir au commit précédent, restaurer les dépendances et reconstruire l’application. Cette étape protège votre calendrier si un fournisseur modifie sa distribution ou si un SDK ne couvre pas votre destination.

Expérience de maintenance : documentez la commande exacte, le fichier modifié et le résultat attendu pour chaque lot. Une procédure de retour arrière non écrite dépend d’une seule personne et devient fragile dès que la machine ou l’équipe change.

Le Mac distant doit être traité comme une machine de validation vierge, non comme le poste personnel d’un développeur. Votre objectif est de confirmer que le dépôt contient assez d’informations pour restaurer les dépendances sans clic manuel ni fichier oublié.

Voici une séquence exploitable en cinq étapes :

1. Préparer un environnement propre. Utilisez une machine ou un volume de travail sans cache de dépendances utile au projet. Notez la version de macOS, de Xcode et des outils de ligne de commande dans le journal de la construction.

2. Récupérer uniquement le dépôt et ses secrets autorisés. Les adresses, identifiants et jetons doivent rester des variables protégées. Dans un exemple public, utilisez des valeurs comme <DEPOT_PRIVE>, <UTILISATEUR_CI> et <JETON_CI>, jamais des accès réels.

3. Restaurer sans mise à jour implicite. Avec CocoaPods, utilisez la procédure correspondant au Podfile.lock et contrôlez les commandes exécutées ; avec Swift Package Manager, vérifiez la résolution liée à Package.resolved. Les commandes de résolution sont décrites dans la documentation Swift officielle.

4. Compiler chaque résultat séparément. Notez si l’échec concerne le téléchargement, la résolution, la compilation du code, les ressources ou la liaison. Ne regroupez pas ces erreurs sous le terme vague « installation ».

5. Produire une Archive et tester le résultat distribué. L’Archive doit être générée avec les mêmes réglages de signature que ceux prévus pour App Store Connect. Contrôlez aussi les extensions, les ressources audio ou vidéo et le démarrage sur la destination cible.

Cette méthode est valable pour une construction locale distante comme pour une CI. Si votre équipe conserve CocoaPods, consultez aussi la référence des commandes CocoaPods afin de rendre la procédure explicite plutôt que dépendante de l’historique du poste.

Pour isoler cette validation sans modifier votre environnement principal, vous pouvez utiliser un Mac distant pour vos essais de build iOS. Le point important n’est pas de déplacer immédiatement la production : c’est de disposer d’une machine propre pour comparer les deux chaînes.

Cochez les affirmations qui décrivent réellement votre projet. Ne cochez pas une case parce qu’elle correspond à la tendance du moment.

Continuer avec CocoaPods

• [ ] Une dépendance critique n’a pas d’équivalent Swift Package Manager officiellement documenté.
• [ ] Le Podfile.lock, le Workspace et les scripts actuels produisent déjà une Archive fiable.
• [ ] La prochaine publication est proche et aucune période de validation n’est disponible.
• [ ] Plusieurs Target dépendent d’une configuration CocoaPods personnalisée.
• [ ] L’équipe sait restaurer les accès privés sans intervention manuelle.

Si toutes les cases critiques sont confirmées, gardez CocoaPods et améliorez la reproductibilité. Réévaluez la situation après la prochaine évolution majeure du projet, pas au milieu d’une livraison.

Migrer vers Swift Package Manager

• [ ] Les dépendances principales fournissent des paquets officiellement compatibles.
• [ ] Les ressources, produits et destinations de chaque paquet sont documentés.
• [ ] Les scripts CocoaPods n’effectuent pas de modification indispensable.
• [ ] Vous pouvez tester compilation, tests et Archive sur une machine propre.
• [ ] Un retour au commit stable reste possible.

Cette option convient particulièrement à un nouveau projet, ou à une application dont les dépendances sont déjà proches du modèle Swift Package Manager.

Rester temporairement en double voie

• [ ] Quelques composants sont faciles à remplacer, mais un SDK central reste sous forme de Pod.
• [ ] Vous pouvez empêcher l’introduction simultanée d’une même bibliothèque.
• [ ] Chaque lot possède un responsable, un résultat attendu et une procédure de retour.
• [ ] La CI peut exécuter une restauration complète sans dépendre d’un cache existant.
• [ ] La publication ne sera pas déclenchée avant la validation de l’Archive.

La double voie doit avoir une condition de sortie. Si personne ne sait quel composant sera migré ensuite, elle devient une nouvelle complexité permanente.

Pour une application audio, vidéo ou de design, le choix dépend souvent moins du gestionnaire que de la distribution du SDK. Un paquet Swift bien maintenu peut être préférable si ses ressources et ses binaires sont correctement déclarés. Un Pod peut rester plus sûr si le fournisseur documente précisément ses scripts de copie, ses codecs ou ses frameworks.

Ne déduisez pas la compatibilité d’une simple compilation de l’écran principal. Testez l’importation d’un fichier audio, le rendu vidéo, le chargement d’une ressource et l’exécution sur appareil physique. Une Archive peut réussir alors qu’une ressource n’est pas embarquée comme prévu.

Votre poste local peut masquer des caches, des certificats, des clés SSH ou des réglages jamais ajoutés au dépôt. Une machine macOS indépendante révèle ces dépendances cachées. Elle permet également de tester une migration sans interrompre votre environnement de développement quotidien.

L’achat d’un Mac reste cohérent si vous avez besoin d’une charge lourde et stable pendant une longue période, d’un accès physique à des périphériques ou d’un poste de travail permanent pour audio et vidéo. En revanche, un poste local dédié uniquement aux essais de migration ou à l’Archive immobilise du capital, demande sa propre maintenance et peut conserver des états invisibles.

La location d’un Mac auprès de KVMNODE est alors plus souple pour une validation limitée par le calendrier du projet : vous pouvez restaurer les dépendances, exécuter les tests et produire des Archives dans un environnement macOS séparé, puis décider si cette chaîne mérite de devenir votre processus permanent. Consultez les options de Mac distant disponibles uniquement après avoir défini vos critères techniques.

CocoaPods n’est donc pas un mauvais choix par principe, pas plus que Swift Package Manager n’est une migration obligatoire. Le premier protège souvent la stabilité d’un projet mature ; le second constitue fréquemment le meilleur point de départ lorsque les paquets officiels couvrent réellement vos besoins. Pour un projet hybride, la décision professionnelle consiste à migrer par lots et à vérifier la restauration complète sur un Mac propre. Si vous ne voulez pas modifier votre poste actuel pour cette campagne de tests, une validation iOS sur un environnement Mac séparé vous permet de mesurer le risque avant de toucher à votre chaîne de publication.