Dernière mise à jour : 22 septembre 2026. Les informations de version et de statut ont été vérifiées à partir des notes de version Xcode publiées par Apple et de la documentation App Store Connect.

Un Archive réussi ne constitue pas une publication terminée. Pour la validation d’une app iOS avant publication avec Xcode 27, il faut franchir au minimum cinq contrôles distincts : identité du projet, intégrité du produit, capacité de signature, livraison du fichier et association correcte dans App Store Connect. Le contrôle final doit aller jusqu’à un build utilisable dans TestFlight ou sélectionnable pour l’envoi en examen ; un Mac distant peut exécuter les opérations répétitives, mais il ne remplace pas la vérification dans App Store Connect.

Cette page s’adresse :

  • aux développeurs indépendants qui soumettent leur première app et veulent savoir quoi vérifier après un Archive ;
  • aux équipes qui entretiennent un Mac distant de compilation et doivent rendre chaque livraison reproductible ;
  • aux petites équipes qui utilisent un script ou une intégration continue pour exporter et téléverser des builds.

Les états de publication

Archive, IPA, téléversement et traitement

Un projet Xcode 27 peut sembler prêt alors que son livrable n’a pas encore atteint l’état attendu. Il faut donc associer chaque étape à une preuve précise, à un responsable et à une condition d’arrêt.

  • Archive réussi : Xcode a produit une archive distribuable dans l’organiseur. Cela prouve que l’opération de compilation et d’archivage est arrivée à son terme, mais pas que le fichier est correctement signé pour la distribution.
  • Export IPA réussi : un fichier destiné à la distribution a été créé avec les options prévues. L’IPA doit provenir de la même archive que celle examinée, et non d’une compilation de débogage ou d’un build destiné au simulateur.
  • Téléversement accepté : Transporter, Xcode ou un autre outil a transmis le fichier au service Apple sans erreur immédiate. Cette confirmation ne signifie pas encore que la plateforme a terminé son analyse.
  • Processing terminé : App Store Connect a traité le build et l’a rendu consultable. Un état d’échec ou un avertissement doit être examiné avant toute conclusion.
  • Build disponible dans TestFlight : le build apparaît sous la bonne fiche d’app et peut être distribué au groupe de test prévu, après les contrôles requis.
  • Build sélectionnable pour l’envoi : la version de l’app dans App Store Connect peut utiliser ce build pour la soumission. C’est cet état, et non la seule présence d’un fichier dans l’historique, qui confirme la dernière étape de livraison.

La documentation Apple sur la distribution d’une app pour les tests et les releases décrit la chaîne de distribution, tandis que les écrans App Store Connect servent à confirmer le résultat côté plateforme.

La règle d’arrêt

La validation doit s’arrêter dès qu’un élément essentiel ne peut pas être prouvé. Par exemple, un script qui affiche un code de sortie réussi sans permettre de retrouver l’archive, le numéro de build, le journal de téléversement et l’état App Store Connect ne fournit pas une preuve suffisante.

Pour chaque livraison, le dossier de suivi devrait conserver :

  • le nom dépersonnalisé du projet et la cible concernée ;
  • la version, le numéro de build et l’identifiant d’app ;
  • l’emplacement de l’Archive et de l’IPA ;
  • le résultat d’exportation et de téléversement ;
  • le message d’erreur ou d’avertissement complet, s’il existe ;
  • la personne qui autorise la poursuite ;
  • la décision finale : corriger, remplacer le build ou continuer vers TestFlight et l’examen.

Identité du projet

Version et numéro de build

La version visible par l’utilisateur et le numéro interne de build ne jouent pas le même rôle. La première identifie la version commercialisée ; le second distingue les livraisons techniques associées à cette version. Ils doivent être contrôlés dans le produit réellement archivé, pas uniquement dans les réglages que le développeur pense avoir modifiés.

Pour effectuer ce contrôle, ouvrez l’Archive dans l’organiseur de Xcode 27, inspectez les informations du produit, puis comparez-les avec la version affichée dans App Store Connect. La documentation Apple sur la préparation d’une app pour la distribution sert de référence pour les éléments à préparer avant la distribution.

Une nouvelle version de l’app nécessite une fiche de version correspondante dans App Store Connect. Pour ajouter une app ou compléter son enregistrement, consultez les instructions Apple relatives à la création d’une fiche d’app. Pour un même numéro de version, un nouveau build peut être utilisé lorsqu’une correction doit remplacer un fichier précédent, à condition que le numéro de build et la relation avec la version soient cohérents.

Un build refusé ou inutilisable ne doit pas être « réparé » en modifiant seulement son nom de fichier. La correction doit produire un nouvel artefact avec une identité contrôlée, puis être téléversée selon les règles du service.

Bundle ID, cible et équipe

Le Bundle ID est l’un des liens qui rattachent le produit à la bonne fiche d’app. Vérifiez les éléments suivants dans la cible finale :

  • le Bundle ID attendu, sans suffixe de test oublié ;
  • la cible effectivement archivée, notamment lorsqu’un projet contient plusieurs applications ou extensions ;
  • l’équipe de développement sélectionnée ;
  • la plateforme et la destination de distribution ;
  • la version et le numéro de build injectés dans le produit ;
  • les extensions, widgets ou composants associés, chacun avec son identifiant prévu.

Le contrôle doit être effectué sur l’Archive et, lorsque c’est pertinent, sur l’IPA exportée. Un réglage correct dans le projet source ne suffit pas si une variable d’environnement, un fichier de configuration ou un script de CI modifie la valeur au moment de l’archivage.

Checklist d’identité

  • [ ] Le Bundle ID de l’Archive correspond à la fiche App Store Connect visée.
  • [ ] La cible archivée est la cible de distribution, et non une cible de démonstration ou de test.
  • [ ] Le nom de l’équipe et le compte de signature sont ceux autorisés pour cette app.
  • [ ] La version affichée dans le produit correspond à la version préparée dans App Store Connect.
  • [ ] Le numéro de build est celui attendu et n’est pas celui d’un ancien artefact.
  • [ ] Les extensions et leurs identifiants ont été contrôlés séparément.
  • [ ] Les valeurs finales ont été lues dans l’Archive ou l’IPA, et non seulement dans le fichier de projet.

Intégrité du produit et signature

Archive et IPA

Un build de simulateur ne peut pas remplacer une archive de distribution. De la même manière, une compilation Debug ne prouve pas qu’une archive Release pourra être exportée, signée et téléversée. Cette distinction est particulièrement importante dans un environnement distant, où un script peut utiliser une destination ou une configuration différente de celle prévue localement.

L’Archive doit être conservée comme source de l’export. Si l’équipe exporte deux IPA à partir de compilations différentes, la comparaison des journaux devient ambiguë : le fichier peut porter la même version tout en contenant un autre numéro de build, une autre signature ou d’autres entitlements.

Contrôlez donc :

  • la configuration Release réellement utilisée ;
  • la présence de l’Archive dans l’organiseur ;
  • la réussite de la validation ou de l’export ;
  • l’IPA produite à partir de cette Archive ;
  • le dSYM conservé pour le même build ;
  • les journaux correspondant à la même exécution.

Certificats, profil et entitlements

La signature ne se résume pas au nom d’un certificat. Le certificat de distribution, le profil de provisioning, les entitlements et l’identifiant de l’app doivent former un ensemble compatible avec la cible. Une permission ajoutée au projet mais absente du profil, ou un profil appartenant à un autre identifiant, peut bloquer l’export ou provoquer un comportement inattendu après installation.

Dans un Mac distant, le trousseau d’accès est un point de contrôle supplémentaire. Une tâche non interactive ne doit pas dépendre d’une fenêtre de confirmation visible uniquement dans une session graphique. Vérifiez la disponibilité du certificat privé, les autorisations d’accès du processus de compilation et la méthode utilisée pour injecter les secrets. Les fichiers contenant des identifiants, des clés privées ou des jetons ne doivent pas être placés dans les journaux.

Attention : une tâche automatisée peut continuer après une étape partiellement réussie. Le journal doit donc enregistrer explicitement la validation de la signature, l’export de l’IPA et le téléversement, au lieu de déduire le résultat de l’absence d’erreur dans une commande précédente.

La documentation Apple consacrée à la préparation de la distribution doit être utilisée pour vérifier les prérequis de signature et de distribution, sans transformer une configuration locale en garantie valable pour toutes les équipes.

Checklist de l’artefact signé

  • [ ] L’Archive provient d’une compilation Release destinée à la distribution.
  • [ ] L’IPA a été exportée depuis cette Archive précise.
  • [ ] Le certificat de distribution et le profil correspondent au Bundle ID.
  • [ ] Les entitlements de l’app et des extensions sont attendus.
  • [ ] Le dSYM est conservé avec le même numéro de build.
  • [ ] Aucun secret n’apparaît dans les journaux ou les fichiers remis à l’équipe.
  • [ ] Le trousseau du Mac distant est accessible au processus non interactif prévu.
  • [ ] Une installation de contrôle utilise l’IPA ou le build final, et non une compilation de développement différente.

Livraison et état App Store Connect

Téléversement et traitement

Après le téléversement, le contrôle doit se déplacer vers App Store Connect. La plateforme peut accepter le transfert puis afficher un traitement en cours, un échec, un avertissement ou un état complet. Ces états ne doivent pas être confondus.

La page Apple dédiée au téléversement des builds explique les canaux acceptés et les conditions générales de livraison. Le résultat de Transporter ou de la ligne de commande constitue une preuve du transfert, mais pas une preuve de traitement terminé.

Pour chaque livraison, notez :

  • l’heure du téléversement et l’identifiant du build ;
  • le numéro de version et le numéro de build ;
  • l’outil utilisé ;
  • le message final de l’outil ;
  • l’état affiché dans App Store Connect ;
  • les avertissements et les erreurs associés ;
  • la décision prise si le traitement échoue ou reste en attente.

La vue Apple des builds et de leurs métadonnées permet de vérifier que le build attendu est bien visible et que ses métadonnées correspondent à l’artefact produit.

Actions selon le résultat

  • Téléversement réussi, traitement en cours : ne téléversez pas immédiatement un doublon ; conservez le journal et attendez que l’état évolue avant de décider.
  • Traitement échoué : relevez le message complet, identifiez si le problème concerne le binaire, la signature, les métadonnées ou la conformité, puis produisez un nouveau build si nécessaire.
  • Traitement terminé avec avertissement : déterminez si l’avertissement bloque TestFlight ou l’envoi en examen ; ne le classez pas automatiquement comme sans conséquence.
  • Build visible sous une mauvaise version : arrêtez la soumission et contrôlez le numéro de version, le Bundle ID et la cible archivée.
  • Build déjà utilisé ou numéro indisponible : ne réutilisez pas mécaniquement un identifiant de build ; incrémentez-le selon la correction apportée et vérifiez l’association obtenue.

Un Mac distant est utile pour exécuter le même script d’Archive, d’export et de téléversement, mais il ne peut pas décider seul qu’un build est correctement rattaché dans App Store Connect. Cette décision reste liée à l’état affiché par la plateforme et à la version de l’app concernée.

TestFlight et envoi en examen

Association du build

Un build marqué comme traité n’est pas forcément le build que l’équipe veut soumettre. Dans App Store Connect, ouvrez la version prévue, repérez le build correspondant à la version et au numéro de build relevés dans l’Archive, puis vérifiez qu’il peut être sélectionné pour l’envoi.

La procédure Apple pour choisir un build à soumettre décrit cette association. Elle doit être vérifiée dans la bonne fiche d’app et pour la bonne plateforme, surtout lorsqu’un compte contient plusieurs produits.

TestFlight, conformité et permissions

Avant l’envoi final, effectuez une installation de contrôle avec le build effectivement traité. Cette installation doit vérifier le lancement, le parcours principal, les achats ou abonnements concernés, les notifications et les fonctions propres à l’app. Pour une application audio, vidéo ou de design, ajoutez un contrôle des importations, des aperçus, de l’export de fichiers et des autorisations multimédias : une archive techniquement valide peut encore présenter un défaut concret à l’usage.

Contrôlez également :

  • l’état de conformité aux règles d’exportation, lorsqu’une réponse est demandée ;
  • les informations manquantes affichées dans App Store Connect ;
  • le groupe TestFlight destinataire ;
  • les métadonnées nécessaires à l’examen ;
  • la cohérence entre le build installé et celui sélectionné pour la soumission.

« Complete » indique que le traitement du build est arrivé à son terme, mais ne signifie pas automatiquement que toutes les informations de soumission sont remplies ni que le build est déjà prêt à être envoyé en examen. Il faut encore vérifier la version, les éléments obligatoires et la sélection du build dans la fiche concernée.

Checklist finale

  • [ ] Le build apparaît sous la bonne application et la bonne version.
  • [ ] Le numéro de build affiché correspond à l’Archive et à l’IPA conservées.
  • [ ] Le build peut être sélectionné pour la version destinée à l’examen.
  • [ ] Les éléments de conformité et d’exportation ne présentent pas de blocage.
  • [ ] Une installation de contrôle a été réalisée avec le build traité.
  • [ ] Le parcours principal fonctionne sur l’app installée.
  • [ ] Les fonctions audio, vidéo, design ou importation propres au produit ont été vérifiées.
  • [ ] Les informations obligatoires de la soumission sont complètes.
  • [ ] Le responsable de la publication a confirmé la décision finale.

Organisation sur un Mac distant

Pour une publication occasionnelle, un Mac local ou une session distante ponctuelle peut suffire, à condition de conserver les artefacts et de refaire les contrôles App Store Connect. Pour une équipe qui répète régulièrement les mêmes opérations, le critère principal n’est pas seulement l’accès à Xcode 27 : il faut pouvoir retrouver l’environnement, les journaux, les secrets autorisés et le résultat d’une reprise après interruption.

Avant d’adopter un Mac distant pour la compilation iOS, définissez une procédure de contrôle :

  • fixer la version de Xcode 27 utilisée par le pipeline ;
  • documenter la destination et la configuration d’Archive ;
  • préparer le trousseau sans exposer les clés privées ;
  • injecter les variables et jetons par un mécanisme contrôlé ;
  • enregistrer l’Archive, l’IPA, le dSYM et les journaux dans un emplacement sécurisé ;
  • faire échouer le script si l’export ou le téléversement ne produit pas la preuve attendue ;
  • vérifier depuis App Store Connect l’état du build après l’exécution ;
  • tester une reconnexion et une reprise sans considérer qu’une session interrompue a terminé la livraison.

Les équipes qui veulent relier cette validation à un pipeline peuvent consulter le guide de compilation iOS avec un Mac distant, puis choisir entre une exécution ponctuelle et un environnement conservé pour les publications répétées. La page des formules Mac de RUVCLOUD peut être examinée seulement après avoir estimé la fréquence réelle des Archives, des exports et des corrections.

Décision avant publication

La checklist est validée uniquement lorsque les cinq preuves sont réunies : l’identité du produit est correcte, l’artefact correspond à la version attendue, la signature est exploitable, le téléversement est confirmé par App Store Connect et le build est associé à la bonne version pour TestFlight ou l’examen.

Un Mac local reste préférable si le développement exige des interfaces physiques, des périphériques connectés ou une utilisation quotidienne interactive. À l’inverse, l’achat d’un Mac dédié peut immobiliser un budget pour une machine peu utilisée, tandis qu’un poste personnel peut manquer de disponibilité lorsqu’un pipeline doit compiler en arrière-plan. Un Mac distant de RUVCLOUD devient alors une option plus cohérente pour les besoins temporaires ou pour une équipe qui doit répéter Archive, export, téléversement et reprise sans laisser une machine locale allumée.

Si les publications sont rares, l’usage ponctuel permet de conserver une décision prudente : préparer les certificats, exécuter la checklist, puis libérer l’environnement. Si les builds sont fréquents, que les échecs doivent être repris rapidement et que l’équipe veut séparer le poste de développement du poste de publication, il est pertinent d’examiner un environnement Mac distant adapté à ce flux, après avoir vérifié les exigences de sécurité et d’accès de l’équipe.