Artefacts Xcode Cloud conservés 30 jours ? Tutoriel de sauvegarde 2026

Vous devez analyser un crash d’un mois passé, mais le build concerné n’est déjà plus téléchargeable.

La solution la plus rapide est d’archiver le jour même les artefacts utiles ; au-delà, Xcode Cloud ne doit pas être considéré comme votre dépôt permanent. Au 30 août 2026, Apple indique que les informations de build et les artefacts restent accessibles pendant 30 jours au maximum.

Cette procédure s’adresse aux développeurs indépendants qui publient avec Xcode Cloud sans conserver séparément leurs livrables, aux mainteneurs qui doivent retrouver les symboles d’une ancienne version et aux petites équipes qui souhaitent utiliser un Mac distant pour télécharger, contrôler et restaurer des xcarchive ou des xcresult.

Le jour du build : classer avant de télécharger

La première erreur consiste à vouloir conserver indistinctement chaque fichier produit par chaque branche. Une sauvegarde utile commence par la valeur de diagnostic et de publication, pas par le volume.

Apple distingue plusieurs familles d’artefacts dans son environnement de compilation. Les éléments exposés par l’API doivent être interprétés dans le contexte de l’exécution, de l’action et du workflow concernés ; la documentation sur les artefacts App Store Connect sert de référence pour cette relation.

Pour une version effectivement distribuée, la priorité est généralement la suivante :

• l’archive d’application xcarchive, qui permet de retrouver le paquet associé à une livraison ;
• les fichiers de symboles, indispensables pour rendre lisibles certains rapports de crash ;
• les résultats xcresult, lorsqu’ils contiennent les diagnostics, tests ou pièces utiles à une enquête ;
• les journaux de compilation et de test, lorsque l’incident concerne une différence entre une exécution réussie et une exécution échouée ;
• les artefacts d’une branche de développement, à conserver seulement s’ils servent à reproduire un défaut ou à documenter une décision.

L’archive, le paquet distribué et le résultat de test ne sont pas interchangeables. Un fichier exporté peut prouver qu’une version a été produite, mais il ne remplace pas nécessairement les données nécessaires à l’analyse d’un crash. De même, un xcresult apporte des informations de test qui ne se trouvent pas automatiquement dans un xcarchive.

Pour les projets audio, vidéo ou de design, cette distinction est particulièrement importante. Une application peut fonctionner dans le simulateur tout en échouant lors de l’export d’un média, de la lecture d’un format ou du traitement d’une ressource volumineuse. Conservez alors les résultats de test et les journaux qui expliquent l’état de l’environnement, au lieu de ne garder que le binaire final.

Le guide Apple de configuration d’un premier workflow Xcode Cloud permet de vérifier le rôle du workflow et de ses actions. Il ne faut pas déduire de la présence d’un build dans l’interface que ce build sera disponible sans limite.

À la fin de la compilation : établir une base traçable

Le téléchargement manuel reste adapté à une publication occasionnelle. Il est aussi indispensable comme référence avant d’automatiser, car il vous permet de comparer le contenu réellement produit avec celui récupéré par le script.

Depuis Xcode ou App Store Connect, ouvrez l’exécution réussie, puis inspectez chaque action et chaque artefact disponible. Apple confirme l’accès aux informations de build et aux artefacts depuis Xcode, App Store Connect ou App Store Connect API, dans la limite de leur fenêtre de disponibilité. Les ressources relatives aux exécutions de build dans App Store Connect API décrivent le point de départ logique pour retrouver cette exécution.

Créez ensuite un répertoire dont le nom permet une recherche directe. Vous pouvez utiliser une convention de ce type, en remplaçant les valeurs sensibles par des identifiants internes :

application-version-numero-build-workflow-date/

Évitez d’insérer dans un nom de fichier une clé d’API, un identifiant de compte ou un chemin contenant des informations personnelles. Le dossier doit néanmoins relier clairement :

• l’application concernée ;
• la version marketing ;
• le numéro de build ;
• le workflow et l’action d’origine ;
• la date de compilation ;
• le résultat de l’exécution ;
• la liste des fichiers téléchargés.

Ne vous contentez pas de renommer une archive en « dernière-version ». Ce libellé perd toute valeur dès qu’un correctif est publié. Pour chaque téléchargement, écrivez un manifeste séparé, par exemple en JSON ou en texte structuré, avec le nom du fichier, sa taille, son empreinte, son origine et l’identifiant du build. L’empreinte ne prouve pas qu’un fichier est fonctionnel, mais elle permet de détecter une modification ou un remplacement silencieux.

Cette étape fournit votre ligne de référence. Ouvrez l’archive dans Xcode, vérifiez que la version et le numéro de build correspondent à App Store Connect, puis notez les résultats. Pour un xcresult, contrôlez qu’il peut être ouvert et que les tests ou diagnostics attendus sont lisibles. La documentation Apple sur l’interprétation des résultats de test aide à distinguer un fichier présent d’un résultat réellement exploitable.

La première semaine : passer du téléchargement manuel à l’API

Lorsque les builds sont fréquents, l’interface devient un point de défaillance opérationnel : quelqu’un doit se souvenir de télécharger le bon artefact, dans la bonne fenêtre, puis de vérifier son contenu. App Store Connect API peut prendre en charge cette répétition, mais elle ne décide pas à votre place ce qui mérite d’être archivé.

Le raisonnement de l’automatisation est le suivant :

• rechercher les exécutions de build correspondant à l’application ou au workflow ciblé ;
• sélectionner les actions pertinentes, en excluant les échecs ordinaires et les branches sans valeur de publication ;
• interroger les artefacts liés à l’action retenue ;
• télécharger chaque fichier dans un répertoire temporaire ;
• vérifier le téléchargement avant de le déplacer vers le stockage définitif ;
• enregistrer le statut, l’identifiant de l’exécution et l’empreinte ;
• marquer l’opération comme terminée afin de ne pas archiver deux fois le même artefact.

Les ressources Xcode Cloud Builds, Actions et Artifacts sont plus utiles que la simple mémorisation d’une liste de routes : elles montrent comment remonter de l’action vers ses artefacts. La référence générale d’App Store Connect API doit être consultée lorsque le schéma, l’authentification ou les paramètres évoluent.

Un exemple de configuration doit rester générique et ne jamais contenir de secret réel :

APP_STORE_CONNECT_ISSUER_ID=<identifiant-editeur>
APP_STORE_CONNECT_KEY_ID=<identifiant-cle-api>
APP_STORE_CONNECT_PRIVATE_KEY_PATH=<chemin-cle-privee>
APP_ID=<identifiant-application>
ARCHIVE_ROOT=<stockage-archives>

Ces valeurs ne représentent pas la même autorité. La clé d’API sert à appeler App Store Connect API. Les certificats et profils de signature servent à produire ou exporter une application. L’accès SSH ou VNC à un Mac distant sert à administrer une machine. Ne mettez pas ces trois catégories dans un même fichier de sauvegarde et ne déposez jamais la clé privée dans le répertoire des archives.

Le script doit aussi prévoir les réponses incomplètes. Un build terminé peut ne pas avoir l’artefact attendu ; un téléchargement peut réussir au niveau HTTP mais produire un fichier vide ou corrompu ; une API peut répondre avec une erreur temporaire. Dans chaque cas, consignez l’état et laissez une nouvelle tentative contrôlée reprendre le travail.

Déclenchement : planification contre événement de fin

Deux modèles conviennent à des contraintes différentes.

Le balayage planifié interroge régulièrement les exécutions récentes et récupère celles qui n’ont pas encore de marqueur d’archivage. Il est simple à opérer et convient à un projet qui publie rarement. Son défaut est le délai entre la fin du build et la sauvegarde, ainsi que le risque de laisser passer une erreur si le job s’arrête.

Le déclenchement par événement réduit ce délai. Xcode Cloud peut envoyer une notification lorsqu’un build atteint un état donné ; la documentation Apple sur la configuration des webhooks Xcode Cloud confirme ce mécanisme. Toutefois, un webhook n’est pas un espace de stockage. Il signale qu’un traitement doit commencer ; il ne conserve pas l’archive à votre place.

Pour choisir :

• publication peu fréquente : planifiez une récupération périodique et conservez une analyse de rattrapage ;
• publication fréquente : déclenchez le téléchargement à la fin du build, puis lancez un balayage complémentaire ;
• incident d’API ou de réseau : réessayez sans créer de doublon ;
• notification reçue plusieurs fois : utilisez l’identifiant du build, du workflow et de l’action comme clé d’idempotence ;
• build échoué : conservez au moins son état et son journal si l’échec est utile à l’enquête.

Cette combinaison événement plus compensation est plus sûre qu’un système qui suppose qu’une seule notification sera toujours reçue. La logique de récupération doit rester capable de retrouver un build dont le webhook a été retardé, perdu ou traité pendant une indisponibilité du stockage.

FAQ : conservation, récupération et analyse des anciens builds

Combien de temps Xcode Cloud conserve-t-il un build ?

Au 30 août 2026, la documentation officielle indique une accessibilité maximale de 30 jours pour les informations de build et les artefacts. Il s’agit d’une limite d’accès documentée, non d’une garantie d’archivage pour vos besoins de maintenance. Une application publiée doit donc exporter ses fichiers importants pendant cette période, puis les conserver dans un emplacement indépendant.

Comment télécharger un xcarchive et les fichiers de symboles ?

Depuis l’exécution concernée dans Xcode ou App Store Connect, repérez l’action de compilation et les artefacts disponibles. Téléchargez l’archive et les symboles associés, puis comparez leur version et leur numéro de build avec l’enregistrement de la livraison. Stockez-les ensemble dans un dossier traçable, avec un manifeste et une empreinte, au lieu de conserver une archive isolée.

App Store Connect API automatise-t-elle réellement la sauvegarde ?

Oui, elle permet de retrouver les exécutions, les actions et les artefacts téléchargeables. Elle ne fournit toutefois ni votre politique de conservation ni votre stockage définitif. Votre automatisation doit filtrer les builds, gérer les erreurs, empêcher les doublons, protéger les identifiants d’accès et produire un journal d’exécution. Sans ces contrôles, vous avez seulement remplacé un téléchargement manuel par un autre point d’échec.

Que faire si un artefact Xcode Cloud n’est plus disponible ?

Cherchez une copie externe validée : stockage d’archives, machine de récupération ou export réalisé au moment de la publication. Ne supposez pas qu’un build disparu de sa fenêtre d’accès sera restaurable depuis Xcode Cloud. Une nouvelle compilation ne constitue pas toujours la même preuve : les dépendances, l’environnement et les fichiers générés peuvent avoir changé.

Quels artefacts conserver pour un crash de production ?

Conservez l’xcarchive de la version distribuée, les symboles correspondant exactement au numéro de build et les informations permettant de retrouver l’exécution. Ajoutez le xcresult et les journaux lorsque les tests ou diagnostics sont nécessaires. Apple décrit l’utilisation des rapports de crash et journaux d’appareil, mais ces rapports ne remplacent pas une politique d’archivage correctement tenue.

Après la publication : vérifier que l’archive pourra vraiment servir

Un téléchargement terminé n’est pas une restauration réussie. Le contrôle doit reproduire le parcours d’un mainteneur qui reçoit un identifiant de version plusieurs semaines après la livraison.

Effectuez les opérations suivantes pour chaque version importante :

• [ ] retrouver l’application, la version, le numéro de build et le workflow à partir du manifeste ;
• [ ] vérifier que l’archive et les symboles sont présents dans le stockage indépendant ;
• [ ] contrôler les empreintes et signaler toute différence avec le manifeste initial ;
• [ ] décompresser une copie de travail sans modifier l’original ;
• [ ] ouvrir l’xcarchive dans Xcode et confirmer ses informations de version ;
• [ ] ouvrir l’xcresult lorsqu’il fait partie du dossier de conservation ;
• [ ] vérifier que les symboles peuvent être associés au build du rapport de crash ;
• [ ] enregistrer le résultat de la restauration et la date du contrôle ;
• [ ] supprimer les données sensibles de la copie utilisée pour la démonstration.

Une restauration de test doit être réalisée dans un environnement séparé de la production. Vous pouvez travailler sur un Mac distant lorsque le contrôle exige Xcode, une session macOS persistante ou l’exécution répétée d’un script de récupération. Cette organisation évite de dépendre du poste personnel d’un développeur qui serait éteint, réinstallé ou occupé par une autre tâche.

Le périmètre de conservation doit aussi rester propre. Les certificats privés, les profils sensibles et les clés d’API ne sont pas des artefacts ordinaires. Ils doivent suivre une gestion séparée, avec des droits limités et une procédure de rotation. Le dossier de restauration peut contenir les références nécessaires à la recherche, mais pas les secrets eux-mêmes.

Conservation durable : attribuer un rôle à chaque emplacement

Une archive locale est rapide à consulter, mais elle dépend du disque et de la machine. Un stockage d’objets généraliste est pratique pour conserver des fichiers et des manifestes, mais il ne remplace pas automatiquement un environnement macOS capable d’ouvrir une archive ou d’exécuter un outil de symbolisation. Un Mac distant permanent peut remplir ce dernier rôle, à condition de ne pas devenir l’unique copie.

Pour une petite équipe, la séparation suivante est raisonnable :

• le stockage principal conserve les archives, symboles, résultats et manifestes ;
• une seconde destination reçoit les copies destinées à la reprise ;
• le Mac distant sert à télécharger, décompresser, ouvrir et analyser ;
• le système d’automatisation conserve les journaux et les états de traitement ;
• les secrets restent dans un coffre ou un mécanisme d’accès séparé.

Ne fixez pas une durée uniforme sans examiner votre produit. Les builds de test interne peuvent être supprimés plus tôt si aucune enquête ne les exige. Les versions candidates méritent une conservation plus stricte jusqu’à la fin de la validation. Les versions publiées doivent rester accessibles aussi longtemps que votre support, vos obligations contractuelles et votre capacité d’analyse l’imposent.

Un contrôle mensuel peut vérifier qu’un échantillon de fichiers est toujours lisible. Après chaque publication, vérifiez immédiatement la présence de l’archive, des symboles et du manifeste. Cette double cadence distingue la vérification de livraison de la vérification de récupération ; elle détecte à la fois un téléchargement manqué et une défaillance silencieuse du stockage.

Comparer les méthodes avant de choisir votre infrastructure

Le choix ne se résume pas à « manuel ou automatique ». Il dépend de la fréquence de publication, du besoin d’ouvrir les archives et du niveau de contrôle attendu.

Si votre équipe publie peu et possède déjà une procédure rigoureuse, le téléchargement manuel peut suffire. Si vous devez conserver chaque version distribuée, l’API devient préférable. Si vous ouvrez régulièrement d’anciens xcarchive, exécutez des scripts ou traitez des rapports de crash, ajoutez un Mac distant à l’architecture plutôt que de demander à chaque développeur de maintenir son propre environnement.

Vous pouvez consulter le choix entre Xcode Cloud et un serveur de compilation iOS permanent avant de décider où placer l’automatisation. Pour une comparaison plus concrète des formules, la page des offres de Mac distant permet ensuite d’évaluer si une machine temporaire ou un nœud permanent correspond à votre cadence.

Quand une location de Mac devient cohérente

Conserver les artefacts dans un stockage indépendant reste indispensable, même avec un Mac distant. La machine ne doit pas être présentée comme une sauvegarde en soi. Elle devient intéressante lorsque la procédure exige régulièrement d’ouvrir Xcode, de relancer une lecture de xcresult, d’exécuter une symbolisation ou de maintenir le script de téléchargement disponible sans dépendre d’un ordinateur personnel.

Un poste local peut manquer d’espace, être éteint au moment du webhook ou mélanger les archives de plusieurs applications. Une solution entièrement fondée sur Xcode Cloud laisse, elle, la récupération dépendre d’une fenêtre d’accès limitée à 30 jours. Un service de location Mac apporte un environnement macOS accessible à distance et des droits d’administration adaptés à vos scripts, mais il ne convient pas forcément à une charge lourde permanente ni aux workflows qui exigent un accès physique à un périphérique.

Si vous avez seulement besoin d’une récupération ponctuelle, un Mac temporaire peut être plus rationnel. Si les téléchargements, contrôles et analyses sont récurrents, examinez plutôt une commande de Mac distant pour vos outils de développement, puis imposez une règle simple : l’archive définitive doit exister dans un stockage séparé et une restauration doit être prouvée avant de considérer le processus fiable.

La décision est donc opérationnelle : utilisez Xcode Cloud pour compiler et tester, App Store Connect API pour récupérer automatiquement les artefacts, un stockage indépendant pour les conserver, et un Mac distant seulement lorsque l’ouverture ou l’analyse macOS fait partie du travail régulier. Cette séparation protège vos anciennes livraisons sans transformer Xcode Cloud en dépôt qu’il n’a pas vocation à être.