Vous pouvez écrire le code TypeScript, modifier les composants d’interface, exécuter les tests Web et produire les fichiers statiques depuis Windows ou Linux. Cette partie ne nécessite pas de Mac. La génération ou la synchronisation d’un projet Capacitor ne signifie toutefois pas que la chaîne iOS complète est disponible.

Pour Capacitor 8, la construction iOS exige macOS, Xcode et les outils de ligne de commande Xcode, comme le précise la documentation officielle de configuration de l’environnement Capacitor. Le guide iOS distingue donc plusieurs états qu’il ne faut pas confondre :

La réponse à la question « Capacitor 8.5 iOS nécessite-t-il un Mac pour construire ? » est donc oui pour le binaire iOS et la livraison complète, mais non pour la plus grande partie du travail Web. Cette séparation vous évite de réserver un nœud macOS pour des vérifications qui peuvent rester sur votre pipeline Linux.

Le dossier ios/ peut être généré ou versionné depuis une organisation centrée sur Linux. En revanche, vous devez exécuter Xcode pour compiler le projet natif, lancer le Simulator, créer une archive et traiter la signature. La documentation iOS de Capacitor constitue la référence à consulter lorsque votre script mélange synchronisation Web et opérations natives.

Ne commencez pas par mettre à niveau Xcode, les dépendances et les plugins sur votre nœud de production. Préparez d’abord une machine de validation séparée, accessible par SSH pour les commandes et par VNC ou console Web pour Xcode et le Simulator.

Votre fiche de référence doit contenir :

• la version de Capacitor utilisée par le dépôt ;
• la version de Node.js et le gestionnaire de paquets réellement sélectionné ;
• la version active de Xcode ;
• le gestionnaire de dépendances iOS ;
• l’état propre du dépôt et le commit testé ;
• le chemin de travail, le nom du projet et l’identifiant d’application sous forme de variables ;
• une méthode de redémarrage et un accès de récupération indépendants du terminal SSH.

Utilisez des variables telles que PROJECT_PATH, BUNDLE_ID_PLACEHOLDER, TEAM_ID_PLACEHOLDER et SIGNING_KEY_PLACEHOLDER. Ne placez ni identifiant réel, ni certificat, ni clé privée dans un exemple de commande ou dans un journal partagé.

Le premier essai doit partir d’un clone vierge. Synchronisez ensuite le plus petit artefact Web reproductible. Cette précaution permet de distinguer trois causes souvent mélangées : un problème de projet Capacitor, une dépendance native absente ou un état implicite laissé par un ancien poste.

Vous pouvez conserver les contrôles suivants sur votre CI Linux :

• installation des dépendances JavaScript ;
• vérification de type ;
• linting ;
• tests unitaires ;
• génération de l’artefact Web ;
• contrôle de taille et de contenu du répertoire de sortie.

Le nœud Mac ne doit recevoir que l’artefact et les opérations iOS nécessaires. Vous limitez ainsi l’attente du nœud et facilitez son remplacement.

Le guide de mise à jour Capacitor 8.5 et les exigences liées à Xcode 27 confirme la migration liée au cycle de vie UIScene. Ce point ne se résume pas à changer le numéro de Xcode. Il faut vérifier les réglages du projet, les fichiers iOS concernés et les entrées Info.plist attendues par votre application.

Contrôlez au minimum :

• la présence et l’enregistrement des fichiers liés à UIScene ;
• les références de fichiers dans le projet Xcode ;
• les entrées Info.plist ajoutées ou modifiées ;
• les points d’entrée utilisés par les plugins ;
• les différences entre le projet généré et le projet conservé dans le dépôt ;
• les avertissements de compilation qui indiquent une migration incomplète.

Xcode 27 est ici une contrainte de compatibilité à vérifier, pas une invitation à moderniser toute votre chaîne au même moment. Si votre dépôt utilise encore CocoaPods, ne transformez pas immédiatement cette migration en condition préalable. Les nouveaux projets Capacitor 8 s’orientent par défaut vers Swift Package Manager, mais un projet existant peut conserver CocoaPods tant que ses dépendances et ses plugins sont compatibles.

L’objectif est d’obtenir un premier build observable, pas de rendre toutes les dépendances « modernes ». Lancez une compilation depuis le terminal avec un espace de travail propre, redirigez la sortie vers un journal horodaté et conservez le chemin de l’artefact.

À titre de structure, adaptez vos variables plutôt que de copier des identifiants réels :

cd "$PROJECT_PATH"
npm ci
npx cap sync ios
xcodebuild \
  -workspace "$IOS_WORKSPACE" \
  -scheme "$IOS_SCHEME" \
  -configuration Release \
  -sdk iphoneos \
  -derivedDataPath "$DERIVED_DATA_PATH" \
  build | tee "$BUILD_LOG"

Les options exactes dépendent de votre projet. Le critère de passage est plus strict qu’un retour sans erreur du script : le journal doit être conservé, l’artefact doit exister et le dépôt doit rester reproductible depuis le clone vierge.

Arrêtez-vous avant la signature si la compilation échoue, si les dépendances sont résolues depuis un emplacement inattendu ou si une modification non documentée apparaît dans le projet. Corrigez d’abord la base. Une signature réussie sur un espace de travail contaminé ne prouve pas que la CI fonctionnera.

Un projet vide ne permet pas de décider si votre Mac distant convient. Sélectionnez un plugin réellement utilisé : liens profonds, notifications, appareil photo ou module personnalisé. Vous devez vérifier le comportement natif, pas seulement l’affichage d’une page Web.

Pour le Simulator, le Mac distant permet généralement d’ouvrir Xcode et l’appareil simulé via VNC ou une console graphique. Le terminal peut piloter une partie des commandes, mais l’observation des autorisations, des alertes et de l’état de l’application reste plus fiable avec une session graphique. La documentation Apple sur l’exécution sur appareils simulés ou physiques décrit la distinction entre ces deux cibles.

Conservez une preuve pour chaque scénario :

• démarrage à froid après installation ;
• reprise après passage en arrière-plan ;
• ouverture par URL ;
• appel du plugin choisi ;
• demande et refus d’une autorisation ;
• état attendu après redémarrage de l’application.

Le Simulator convient aux écrans, aux flux de navigation et à l’automatisation. Il ne remplace pas un appareil physique pour les fonctions dépendantes d’un capteur, d’un appareil photo réel, d’une notification poussée ou d’un comportement matériel particulier. Votre plan de qualité doit donc réserver une étape sur appareil réel avant la publication.

Point de contrôle : si le plugin échoue uniquement après reprise en arrière-plan ou après une modification d’autorisation, bloquez la décision CI. Un build vert ne compense pas une régression de cycle de vie.

Cette phase répond aussi à la question de la validation des plugins dans une CI distante : le pipeline doit installer le projet depuis zéro, lancer les scénarios pertinents et publier les journaux ainsi que les captures ou rapports nécessaires. Si le plugin exige une interaction physique, marquez explicitement ce test comme hors périmètre du Simulator au lieu de le déclarer réussi.

Une fois la compilation et les plugins validés, séparez le contrôle Web de la chaîne macOS. Le premier pipeline peut produire l’artefact JavaScript. Le second synchronise ce résultat, compile, archive et prépare la distribution. Cette séparation empêche les tâches Linux de monopoliser le Mac.

La signature constitue une frontière opérationnelle distincte. Séparez :

• le compte de construction sans privilège de publication ;
• les certificats et clés privées ;
• les secrets nécessaires à l’API de distribution ;
• les journaux de build accessibles à l’équipe ;
• l’approbation humaine avant l’envoi.

Les identifiants réels doivent rester dans le coffre de secrets de votre CI. Utilisez BUNDLE_ID_PLACEHOLDER, TEAM_ID_PLACEHOLDER et KEYCHAIN_PATH_PLACEHOLDER dans la documentation. Le trousseau temporaire doit être créé pour l’exécution, déverrouillé uniquement pendant la tâche nécessaire, puis supprimé ou réinitialisé selon votre politique.

Pour l’archive et la distribution, appuyez-vous sur la documentation Apple consacrée à la distribution des applications. Pour les informations de débogage et les variantes de compilation, consultez également les instructions Apple sur la construction avec les symboles de débogage.

Le passage est validé seulement si un nouvel espace de travail peut :

• récupérer le dépôt et les dépendances autorisées ;
• produire l’archive sans intervention locale cachée ;
• retrouver les réglages de signature attendus ;
• conserver le journal et l’artefact ;
• s’arrêter avant l’envoi lorsqu’une approbation est requise ;
• permettre la révocation des informations d’identification.

Ne stockez jamais le certificat, la clé privée ou la clé API dans le dépôt. Ne donnez pas à un nœud de test les droits d’un nœud de publication permanente.

Le choix ne doit pas reposer sur la seule durée d’une compilation. Évaluez plutôt la fréquence des versions, le nombre de plugins natifs, la nécessité d’un environnement stable, le temps d’attente, la responsabilité de la signature et la facilité de récupération après redémarrage.

Pour une équipe sans Mac, le choix d’un Mac distant pour le développement peut servir de point de comparaison avec une construction ponctuelle. Consultez aussi les options de Mac mini distant pour les charges de développement si vous devez conserver un environnement accessible entre deux exécutions.

Utilisez cette liste avant de signer une période plus longue :

• [ ] Le clone vierge produit le même projet iOS que le dépôt de référence.
• [ ] La version active de Xcode et les outils de ligne de commande sont enregistrées.
• [ ] La migration UIScene et les entrées Info.plist sont vérifiées.
• [ ] Le choix entre Swift Package Manager et CocoaPods est documenté.
• [ ] Au moins un plugin réellement utilisé passe un scénario de reprise.
• [ ] Le comportement du Simulator est distingué des tests sur appareil physique.
• [ ] L’archive est produite avant toute étape d’envoi.
• [ ] Les certificats, clés et accès API sont isolés des comptes ordinaires.
• [ ] Un redémarrage du nœud ne détruit pas les informations nécessaires à la reproduction.
• [ ] Une procédure de retrait ou de révocation des secrets est testée.

Si toutes les cases sont cochées et que les versions natives changent rarement, un Mac distant peut devenir un nœud CI durable. Si la migration reste en cours, gardez une double voie : contrôles Web sur Windows ou Linux, validation iOS sur macOS. Si vous ne publiez qu’occasionnellement et que le projet ne demande pas de débogage natif régulier, une construction temporaire évite de maintenir une machine entre deux livraisons.

Une machine Windows ou Linux reste excellente pour le développement Web, mais elle bloque la compilation iOS, le Simulator, l’archivage et la validation de plugins natifs. Une construction temporaire, de son côté, laisse moins de contrôle sur la version active de Xcode, l’état du trousseau et la répétition des essais. Dans les deux cas, vous risquez de recréer l’environnement au moment le plus sensible, juste avant la publication.

Après votre premier cycle complet, louer un Mac auprès de KVMNODE peut offrir un environnement macOS accessible par SSH, VNC ou console Web, avec une continuité plus adaptée aux corrections, aux essais de plugins et à la reprise d’un pipeline. La bonne décision reste conditionnelle : choisissez cette formule si vous avez besoin d’un poste contrôlable pendant toute la période de validation ; restez sur une exécution ponctuelle si votre projet est stable et vos publications rares. Pour une équipe qui doit conserver son nœud entre plusieurs versions Capacitor, vous pouvez examiner les options de Mac distant disponibles chez KVMNODE, puis comparer la durée d’essai aux preuves recueillies dans la liste précédente.