Passer à la navigation principale
Mise à jour

Comment migrer votre application Capacitor vers le gestionnaire de packages Swift

Apprenez à déplacer une application iOS existante Capacitor de CocoaPods vers le gestionnaire de packages Swift avec l'assistant de migration officiel, les vérifications Xcode et la mise à jour de la CI.

Crédits de l'article

Martin Donadieu

Écrivain

Valeria

Relecteur

Jordan

Éditeur

Comment migrer votre application Capacitor vers le gestionnaire de packages Swift

Manger de packages Swift est la direction par défaut pour les projets Capacitor iOS. Si votre application utilise toujours CocoaPods, vous pouvez migrer l'application elle-même vers SPM sans reconstruire votre projet JavaScript code, votre projet Android ou votre flux de publication de l'application depuis zéro.

Cette guide est destiné aux équipes d'applications. Il explique comment migrer une application Capacitor iOS de CocoaPods vers SPM, ce que change l'assistant de migration, ce que vous devez toujours vérifier dans Xcode et comment nettoyer CI après que l'application a été construite.

Quels changements dans l'application

Une application Capacitor basée sur CocoaPods dépend de fichiers tels que :

  • ios/App/Podfile
  • ios/App/Podfile.lock
  • ios/App/Pods/
  • ios/App/App.xcworkspace

Une application Capacitor basée sur SPM déplace la mise en câble des dépendances iOS dans Manger de packages Swift. Lors de la migration, Capacitor crée un package local nommé CapApp-SPM et utilise-le pour relier la cible de l'application avec Capacitor et les dépendances natives installées.

La construction web fonctionne toujours de la même manière. Vous exécutez toujours une construction web, synchronisez Capacitor, ouvrez Xcode et archivez l'application. La principale différence est que CocoaPods ne possède plus le graphique de dépendances iOS.

Avant de migrer

Démarrez depuis une branch clean et assurez-vous que l'application actuelle se construit avant de modifier les gestionnaires de dépendances :

git status
npm run build
npx cap sync ios

Ensuite, commitez l'état fonctionnel. La migration touche les fichiers de projet iOS générés, il est donc important d'avoir un point de rebondage de rollback propre.

Ensuite, passez en revue ce que votre application a personnalisé sous ios/App/Les fichiers et les paramètres courants à conserver incluent :

  • App/Info.plist
  • App/AppDelegate.swift
  • App/SceneDelegate.swiftSi elle est présente
  • App/Assets.xcassets/
  • App/Base.lproj/
  • App/App.entitlements
  • App/GoogleService-Info.plistSi vous utilisez Firebase
  • personnalisé .xcconfig fichiers
  • paramètres de signature, identifiant de l'application, ID d'équipe et profils de provisionnement
  • extensions de l'application, fichiers Swift natifs, fichiers Objective-C ou frameworks intégrés

Vérifiez également vos dépendances Capacitor et Cordova installées. Une migration SPM d'une application peut être bloquée par une dépendance native qui n'a pas de chemin compatible SPM. Mettez à jour ces packages avant de migrer lorsque possible.

Utilisez l'assistant de migration

Pour la plupart des applications existantes, commencez par l'assistant de migration officiel Capacitor :

npx cap spm-migration-assistant

Exécutez-le depuis la racine de votre projet Capacitor. CapApp-SPM L'assistant supprime l'intégration de CocoaPods, crée le package local, génère des références de package pour les dépendances natives installées et ajoute la configuration générée nécessaire par le projet iOS.

Après qu'il ait terminé, ouvrez le projet iOS :

npx cap open ios

Lu le résultat de l'assistant avant de fermer votre terminal. Si cela vous demande de compléter des étapes manuelles Xcode, faites-les avant de synchroniser à nouveau.

Terminer les étapes Xcode

Dans Xcode, vérifiez la configuration du projet et de la cible de l'application :

  1. Confirmer CapApp-SPM est ajouté comme une dépendance de package local.
  2. Confirmer que la cible de l'application relie les produits de package générés.
  3. Ajouter le debug.xcconfig à la configuration du projet si l'assistant vous le demande.
  4. Résoudre les avertissements de package dans Xcode.
  5. Construire l'application une fois depuis Xcode.

Si Xcode ne peut pas résoudre les packages, utilisez Ouvrir > Packages > Réinitialiser les caches de packagesEnsuite, résolvez à nouveau les packages.

Synchro et construction à nouveau.

Après la configuration de Xcode, retournez à la console et synchronisez Capacitor :

npx cap sync ios

Reprenez ensuite la construction à partir de Xcode. N'oubliez pas que la migration n'est pas terminée tant que la construction propre fonctionne à partir de Xcode, car la signature de version de sortie, les autorisations, les extensions d'application et la résolution des packages sont validées là.

Si l'application utilise les notifications push, les domaines associés, les modes de fond, les groupes d'application, Firebase ou toute configuration native SDK, exécutez ces flux sur un simulateur ou un appareil après que la construction réussisse.

Alternative : recréer iOS avec SPM

Si votre ios/ dossier est proche du modèle par défaut Capacitor, il peut être plus rapide de le recréer avec SPM au lieu de migrer en place.

Utilisez uniquement cette voie après avoir commit ou sauvegardé tous les fichiers natifs et les paramètres de signature que vous avez besoin :

rm -rf ios
npx cap add ios --packagemanager SPM
npx cap sync ios
npx cap open ios

Reprenez ensuite vos fichiers et paramètres natifs spécifiques à l'application. Cette voie vous donne un projet SPM propre, mais il est plus facile de perdre les modifications Xcode personnalisées si vous n'avez pas inventorié les modifications avant.

Pour les nouvelles applications Capacitor, Capacitor 8 crée des projets iOS avec SPM par défaut :

npx cap add ios

Vous pouvez toujours être explicite :

npx cap add ios --packagemanager SPM

Nettoyez les résidus de CocoaPods

Après la construction de l'application SPM, supprimez les hypothèses de CocoaPods restantes des scripts locaux et de CI.

Supprimez les étapes comme :

pod install

Supprimez également les caches qui n'existaient que pour CocoaPods :

  • ios/App/Pods
  • ios/App/Podfile.lock
  • Les dépôts de spécifications CocoaPods
  • Les clés de cache CI basées sur le Podfile

Un flux CI de base après migration devrait installer les dépendances JavaScript, construire l'application web, synchroniser Capacitor et construire avec Xcode :

npm ci
npm run build
npx cap sync ios

Si votre CI construit toujours App.xcworkspace, mettez à jour vers le chemin du projet ou du dossier de travail qui existe après la migration. N'entretenez pas les anciens chemins CocoaPods juste parce que l'ancien job les utilisait.

Résolution des problèmes

Le conseiller alerte sur une dépendance incompatible

Mettez à jour la dépendance en premier et exécutez le conseiller à nouveau. Si aucune version SPM compatible n'existe, maintenez l'application sur CocoaPods jusqu'à ce que vous remplacez cette dépendance ou que le mainteneur ajoute la prise en charge SPM.

Xcode ne peut pas résoudre les packages

Réinitialisez les caches de packages dans Xcode, assurez-vous que CapApp-SPM est présent en tant que package local, et exécutez npx cap sync ios à nouveau.

L'application se construit localement mais échoue en CI

Recherchez les anciennes hypothèses de CocoaPods : pod install, Pods/ caches, Podfile.lock clés de cache ou des commandes de construction qui pointent vers un fichier supprimé .xcworkspace.

Signature ou droits modifiés

Comparez la cible migrée Xcode avec le projet avant migration. Restaurez l'identifiant de l'application, l'équipe, le profil de provisionnement, le fichier d'autorisation, les capacités et les paramètres d'extension.

Liste de vérification de la migration

Avant la migration :

  • Créez une branche.
  • Confirmez que l'application iOS actuelle se construit.
  • Commitez l'état de travail.
  • Effectuez l'inventaire des fichiers natifs personnalisés et des paramètres de signature.
  • Mettez à jour les dépendances natives qui disposent déjà de versions plus récentes compatibles avec SPM.

Durant la migration :

  • Exécutez npx cap spm-migration-assistant.
  • Ouvrez le projet avec npx cap open ios.
  • Ajoutez CapApp-SPM dans Xcode si nécessaire.
  • Ajoutez debug.xcconfig dans Xcode si nécessaire.
  • Résolvez les avertissements de package.
  • Exécutez npx cap sync ios.

Après la migration :

  • Construirez l'application à partir de Xcode.
  • Testez les capacités natives sur un simulateur ou un appareil.
  • Supprimez les commandes CocoaPods du CI.
  • Supprimez les caches CocoaPods uniquement.
  • Vérifiez l'archivage et la signature de version de sortie.

Utilisez Capgo Compétences pour la migration

Si vous utilisez des agents AI pour gérer la migration, commencez par Capgo Compétences au lieu d'une invitation vide. Les compétences les plus utiles pour ce travail sont :

  • capacitor-best-practices avant de modifier ios/.
  • cocoapods-to-spm pour planifier les étapes de migration vers SPM et les étapes suivantes sur Xcode.
  • capacitor-ci-cd pour supprimer les hypothèses de CocoaPods des pipelines de construction.
  • debugging-capacitor et ios-android-logs pour enquêter sur les problèmes de périphérique uniquement après la migration.

Utilisez-les avant de modifier le projet iOS afin que l'agent effectue des audits de fichiers natifs, CI et compatibilité de dépendances au lieu de seulement exécuter la commande de migration.

Conclusion

Migrer une application Capacitor vers Swift Package Manager est principalement une modification de gestion de dépendances iOS. Le chemin le plus sûr est de commencer d'une branche vierge, de lancer npx cap spm-migration-assistantfinir les étapes manuelles de Xcode, synchroniser à nouveau, et supprimer CocoaPods des CI uniquement après que l'application se construit.

Si votre projet iOS est fortement personnalisé, migrez en place. Si il est proche du modèle de base Capacitor , recréer ios/ avec npx cap add ios --packagemanager SPM peut être plus propre.

Ressources

Actualisations en direct pour les applications Capacitor

When a web-layer bug is live, ship the fix through Capgo instead of waiting days for app store approval. Users get the update in the background while native changes stay in the normal review path.

Support humain de Martin

Démarrer maintenant

Dernières actualités de notre blog

Capgo vous donne les meilleures informations dont vous avez besoin pour créer une application mobile vraiment professionnelle.