Comment compiler après un App Transfer dans App Store Connect ? Liste de transfert 2026

Le symptôme est connu : l’application apparaît bien dans le compte repreneur, mais la première archive échoue ou arrive dans App Store Connect sans les bonnes capacités.

La solution la plus sûre est de ne pas réutiliser directement les identifiants de l’ancienne équipe : vérifiez d’abord le Bundle ID et les capacités transférées, recréez ensuite la signature, les notifications et l’authentification d’envoi sur un Mac distant, puis validez une archive réelle jusqu’à TestFlight. Pendant cette période, conservez une courte double voie avant de retirer l’ancien environnement.

Cette liste s’adresse aux développeurs qui cèdent une application, à ceux qui la reprennent et aux petites équipes chargées d’un Mac de compilation distant. Elle convient aussi aux projets iOS ou macOS qui utilisent Xcode, des scripts d’export, des notifications, des services iCloud, Sign in with Apple ou des flux automatisés de publication.

Un App Transfer modifie l’équipe propriétaire de l’application dans l’écosystème Apple. Il ne déplace pas automatiquement tout ce qui se trouve sur le disque du cédant, dans son trousseau ou dans son serveur d’intégration. Apple indique que le Bundle ID est conservé et que l’App ID associé est transféré au repreneur, mais cette règle ne signifie pas que le code source, les clés privées, les profils locaux et les secrets serveur sont copiés avec l’application. L’aperçu officiel du transfert d’application doit rester la référence principale.

Trois frontières doivent être écrites dans le procès-verbal de remise :

• La fiche App Store Connect : elle contient l’application, ses versions, ses informations de distribution et son historique selon le périmètre prévu par Apple.
• L’identité de signature : elle comprend le Bundle ID, l’App ID, les certificats, les profils d’approvisionnement, les entitlements et les clés privées.
• L’environnement de production : il inclut le dépôt source, les dépendances, les scripts, les archives, les fichiers de configuration, les clés d’API, les webhooks, les secrets APNs et le Mac de compilation.

Le cédant doit donc préparer une remise lisible, et non simplement envoyer une invitation au compte repreneur. Avant de lancer le transfert, il doit contrôler les critères Apple, notamment l’état de l’application, les versions en cours et les conditions liées au compte. Les conditions officielles sont détaillées dans la page consacrée aux critères d’App Transfer.

Attention. Apple Pay Merchant ID ne suit pas automatiquement l’application transférée. Une intégration qui fonctionne en production peut donc nécessiter une décision distincte sur le marchand, les identifiants et la configuration serveur. Ne classez pas Apple Pay dans la catégorie des capacités ordinaires.

Le cédant doit remettre au minimum :

• le code source correspondant à la dernière version publiée et à la prochaine version prévue ;
• le fichier de projet ou d’espace de travail Xcode, les réglages de compilation et la liste des dépendances ;
• les scripts d’archive, d’export IPA, de signature et d’envoi ;
• les archives utiles, les fichiers dSYM et les informations de correspondance des symboles ;
• la liste des capacités activées, avec leurs entitlements et leur usage réel ;
• la configuration APNs, les identifiants de service, les paramètres de Sign in with Apple et les contraintes iCloud ;
• les clés d’API App Store Connect, les webhooks et les variables utilisées par la chaîne d’intégration ;
• une procédure de restauration qui ne dépend pas d’un compte personnel invisible.

Il ne doit pas transmettre un dossier Keychain complet sans inventaire. Le repreneur doit savoir quel secret est nécessaire, à quel service il correspond, où il est injecté et comment il sera révoqué.

Le repreneur ne doit pas commencer par modifier les scripts. Il doit d’abord confirmer que l’application est visible dans App Store Connect, que le Bundle ID attendu est associé au bon projet et que l’App ID présente les capacités nécessaires. L’acceptation suit la procédure décrite par Apple dans la documentation d’acceptation d’un transfert.

Le contrôle doit être réalisé avec une matrice d’identité, sans recopier de secrets réels :

Cette distinction évite une erreur fréquente : confondre la conservation du Bundle ID avec la conservation de toute la chaîne de signature. Apple précise que certains certificats de notification peuvent rester valides pendant leur période de validité, mais l’équipe repreneuse doit préparer ses propres certificats ou clés pour les envois futurs. Les détails de la configuration TLS avec APNs figurent dans la documentation officielle APNs.

Les capacités exigent un contrôle séparé :

• Push Notifications : le serveur d’envoi doit reconnaître la nouvelle identité et utiliser une méthode encore autorisée.
• Associated Domains : le fichier de domaine associé et les entitlements doivent correspondre à la nouvelle archive.
• Keychain Sharing : un changement d’équipe peut affecter l’accès à des éléments enregistrés précédemment ; il faut tester une installation de mise à jour, pas uniquement une nouvelle installation.
• iCloud : les conteneurs, environnements et autorisations doivent être contrôlés dans le compte repreneur.
• Sign in with Apple : les utilisateurs existants peuvent nécessiter une migration spécifique. Apple décrit cette opération dans sa note technique sur la migration des utilisateurs Sign in with Apple.
• Mac Catalyst : la cible macOS, ses capacités et son profil doivent être traités séparément de la cible iOS.
• Webhooks : l’URL, le secret de vérification et les droits du compte doivent être réenregistrés ou confirmés selon le service concerné.

Un transfert peut donc être accepté alors que l’application n’est pas encore publiable depuis le nouvel environnement. Le statut « visible dans App Store Connect » est un contrôle administratif ; il ne remplace ni une archive signée, ni un traitement terminé, ni une installation de test.

La nouvelle équipe doit créer ses propres éléments de signature dès que le Bundle ID et les capacités ont été confirmés. La méthode exacte dépend des cibles et du type d’export, mais la logique reste constante : identifier le projet, générer les actifs de la nouvelle équipe, associer les capacités, puis tester l’IPA obtenue.

Pour une distribution destinée à App Store Connect, le repreneur peut commencer par créer le profil adapté dans son compte, en suivant les étapes Apple relatives à la création d’un profil d’approvisionnement App Store Connect. Il doit ensuite vérifier dans Xcode :

1. le Bundle ID configuré pour chaque cible ;
2. l’équipe sélectionnée pour la signature ;
3. le certificat Apple Distribution utilisé ;
4. le profil choisi pour l’export ;
5. les entitlements réellement présents dans l’archive ;
6. les extensions, widgets et services associés ;
7. les variables qui ne doivent jamais être intégrées en clair au dépôt.

Durant la transition, nous recommandons une double voie limitée. L’ancien environnement peut rester disponible pour une comparaison ou un retour contrôlé, mais il ne doit pas recevoir de nouvelles clés sans décision explicite. Le nouvel environnement doit, lui, produire une archive avec les identifiants de la nouvelle équipe. Tant que cette archive n’est pas installable et que les fonctions critiques ne sont pas testées, la révocation de l’ancien accès est prématurée.

Cette approche est plus sûre que la copie intégrale du trousseau. Une copie totale mélange les certificats expirés, les clés privées inutiles, les comptes personnels et les secrets d’autres applications. Elle rend aussi l’audit difficile : après un échec, il devient impossible de savoir si Xcode a utilisé le nouvel élément ou un ancien certificat resté dans le trousseau.

Le Mac distant doit être traité comme un environnement de publication, pas comme un simple ordinateur partagé. Le mainteneur doit créer un accès séparé pour la nouvelle équipe, documenter la version de Xcode utilisée, verrouiller les chemins de travail et choisir une injection de secrets qui ne dépend pas du profil personnel du cédant.

Dans l’interface graphique, il faut vérifier l’ouverture du projet, la sélection de l’équipe, la résolution des dépendances, l’archive et l’export. Ensuite, une seconde exécution doit être réalisée par SSH ou par le système d’intégration continue, avec des variables masquées telles que :

• TEAM_ID=<TEAM_NEW> ;
• BUNDLE_ID=<APP_BUNDLE_ID> ;
• KEY_ID=<KEY_ID_NEW> ;
• ISSUER_ID=<ISSUER_ID> ;
• ARCHIVE_PATH=<CHEMIN_LOCAL> ;
• EXPORT_OPTIONS_PATH=<CHEMIN_LOCAL>.

Ces valeurs sont des emplacements de configuration, pas des identifiants à recopier tels quels. Aucun mot de passe, jeton ou contenu de clé privée ne doit apparaître dans les journaux, les captures d’écran ou le dépôt.

Le test doit séparer quatre résultats :

• Archive Xcode réussie : le projet a été compilé et l’archive a été créée.
• IPA exportée : le paquet signé a été produit avec les bons entitlements.
• Téléversement accepté : App Store Connect a reçu le paquet.
• Traitement terminé et installation TestFlight : la plateforme a traité la version et un testeur peut l’installer.

Apple distingue les états des constructions après l’envoi ; consultez sa page sur les statuts des builds au lieu de considérer la fin de l’upload comme une validation. Pour la procédure d’envoi, utilisez également la documentation Apple sur le téléversement des builds.

Si le projet contient des ressources audio, vidéo ou graphiques lourdes, le mainteneur doit vérifier que les fichiers sont bien présents dans l’archive et que le traitement ne supprime pas une ressource attendue. Une compilation réussie ne garantit pas qu’un catalogue de sons, une police, une extension ou un paquet de textures soit correctement inclus. Pour les applications créatives, cette vérification sur l’appareil est aussi importante que le contrôle de signature.

La première publication du repreneur doit être une vraie opération, mais son risque doit rester maîtrisé. Il ne suffit pas de lancer une archive locale puis de déclarer la migration terminée. Nous conseillons de conserver une version de référence, d’installer l’IPA de test sur un appareil autorisé et de consigner les résultats dans un journal de remise.

La séquence d’acceptation est la suivante :

• [ ] l’application apparaît dans le compte de la nouvelle équipe ;
• [ ] le Bundle ID du projet correspond à celui attendu ;
• [ ] les cibles iOS, macOS, extensions et widgets utilisent les bonnes équipes ;
• [ ] les profils et certificats du repreneur sont présents ;
• [ ] l’archive contient les entitlements prévus ;
• [ ] l’IPA est exportée sans utiliser par erreur l’ancien trousseau ;
• [ ] l’envoi est accepté par App Store Connect ;
• [ ] le traitement du build atteint un état exploitable ;
• [ ] l’application est installable via TestFlight ;
• [ ] les notifications arrivent sur un appareil réel ;
• [ ] la connexion, l’achat intégré, la synchronisation et les services cloud essentiels fonctionnent ;
• [ ] les symboles et journaux sont récupérables après le test.

Les achats intégrés, les comptes utilisateurs et les services cloud ne doivent pas être vérifiés uniquement avec une nouvelle installation. Une mise à jour depuis la version publiée permet de révéler des problèmes de trousseau, de migration de compte ou de persistance des données qui resteraient invisibles dans une installation vierge.

L’ancien Mac de compilation peut-il rester utilisé ?

Oui, mais seulement comme environnement de comparaison temporaire. Il ne faut pas confondre continuité de fonctionnement et transfert de propriété des secrets. Tant que l’ancienne machine contient le compte, les profils ou les clés privées du cédant, son accès doit être restreint, journalisé et destiné à la récupération. La publication de référence doit progressivement basculer vers le Mac contrôlé par le repreneur.

Que faire des certificats et profils existants ?

Commencez par inventorier leur équipe, leur date d’expiration, leur cible et leur usage. Ne révoquez pas l’ancien certificat avant d’avoir produit une archive avec les éléments du repreneur, sauf incident de sécurité. Le nouveau profil doit être créé après vérification du Bundle ID et des capacités. Les profils locaux ne sont pas des preuves suffisantes : l’IPA exportée et ses entitlements doivent être inspectés.

Les notifications APNs exigent-elles une nouvelle configuration ?

La réponse dépend du type de certificat ou de clé utilisé, mais une migration fiable doit prévoir une nouvelle configuration côté repreneur. Un ancien certificat encore valide peut expliquer pourquoi les notifications continuent temporairement ; il ne doit pas devenir la seule stratégie. Créez un test d’envoi, identifiez le nouvel identifiant serveur et prévoyez une révocation ordonnée de l’ancien secret après validation.

Comment réussir la première archive sur le Mac distant ?

Commencez par une archive graphique avec le projet propre et le compte de la nouvelle équipe. Contrôlez ensuite le fichier d’export, produisez l’IPA, puis répétez l’opération par SSH ou intégration continue avec des secrets injectés. Après l’envoi, attendez le traitement App Store Connect, installez la version TestFlight et testez les fonctions qui utilisent des entitlements, au lieu de vous arrêter au message « Archive succeeded ».

Quels éléments sauvegarder avant le transfert ?

Le paquet de sauvegarde doit inclure le code, les scripts, les réglages Xcode, les dépendances, les archives, les dSYM, les entitlements, la configuration APNs, les paramètres de services et les informations de publication. Il doit aussi préciser ce qui n’est pas transférable ou doit être recréé, notamment Apple Pay Merchant ID et certains secrets personnels. Les clés privées doivent être remises de façon ciblée, jamais sous forme de trousseau complet non documenté.

L’ancien Mac, les anciens runners, les webhooks, les clés d’API et les accès de signature ne doivent être retirés qu’après la validation de la chaîne complète. Le responsable de publication doit conserver les preuves utiles : identifiant du build, archive, IPA, résultat du traitement, journal d’installation et résultat des tests fonctionnels.

Le cédant peut arrêter son environnement lorsque le repreneur a confirmé la récupération du code et des actifs nécessaires. Le repreneur peut demander la révocation des accès lorsque sa propre archive est installable et que les services critiques ont été testés. Le mainteneur du Mac distant peut supprimer l’ancien compte lorsque les journaux ont été exportés, que les secrets inutiles ont été révoqués et qu’aucun déploiement planifié ne dépend encore de ce compte.

Notre règle de décision est simple :

• si l’archive du repreneur échoue, maintenir l’ancien environnement et corriger la signature ;
• si l’IPA est produite mais que le traitement échoue, conserver les deux voies et analyser le paquet ;
• si TestFlight fonctionne mais qu’une capacité critique échoue, ne pas publier en production ;
• si l’installation et les fonctions essentielles sont validées, retirer progressivement les anciens secrets ;
• si l’équipe ne peut pas expliquer quel compte a signé l’IPA, suspendre la publication et refaire l’export dans un environnement propre.

Pour une équipe qui ne souhaite pas acheter un Mac réservé à cette transition, un Mac distant peut éviter trois contraintes du modèle local : immobiliser du capital dans une machine peu utilisée, maintenir une machine allumée pour les intégrations et exposer un trousseau de production sur un poste personnel. En revanche, la location n’est pas le meilleur choix pour une charge lourde permanente, pour un besoin de périphérique physique ou pour une équipe qui exige une maîtrise matérielle locale. Lorsque le besoin porte sur une période de transfert, une validation TestFlight ou une chaîne de publication temporaire avec accès administrateur, les environnements Mac de JEXCLOUD permettent de séparer l’ancien compte du nouvel environnement ; les offres de Mac distant peuvent ensuite être évaluées selon la durée réelle de la double voie.

Avant de fermer l’ancien accès, imprimez ou copiez cette séquence : transfert accepté, Bundle ID confirmé, capacités contrôlées, signature recréée, archive produite, IPA exportée, build traité, TestFlight installé, services critiques testés, journaux conservés, anciens secrets révoqués. C’est cette chaîne complète — et non la seule présence de l’application dans App Store Connect — qui prouve que la remise est terminée.