Symptôme : App Store Connect refuse l’envoi avec « Unsupported SDK or Xcode ». Réponse rapide : ne reconstruisez pas et ne renvoyez pas immédiatement le même Archive ; relevez le refus, vérifiez le Xcode réellement appelé, puis comparez-le à l’état de soumission confirmé par Apple. La version finale Xcode 27.2 et son Release Candidate ne sont pas interchangeables.
Ce diagnostic s’adresse aux développeurs indépendants qui préparent une publication iOS, aux équipes qui maintiennent plusieurs applications et aux petites équipes utilisant un Mac distant. Il vous aide à distinguer un problème d’outil de chaîne d’un défaut de compilation, de signature ou d’examen de l’application.
Localiser précisément l’étape qui a échoué
« Envoi refusé » décrit souvent plusieurs situations différentes. Avant de modifier le projet, identifiez le dernier état effectivement atteint : échec de compilation ou d’archivage, refus au transfert, erreur pendant le traitement du build, ou rejet après examen de l’application. Ces états n’ont pas la même cause et n’appellent pas la même réponse.
App Store Connect distingue notamment les statuts de chargement et de traitement des builds dans sa documentation sur les états de chargement. Utilisez le statut affiché et le message exact comme point de départ : un transfert refusé n’est pas un build en attente de traitement, et un problème d’examen n’est pas une erreur de téléversement.
Conservez les éléments qui permettent de reconstituer l’incident :
- Le texte intégral du message, sans le réduire à « échec d’envoi ».
- Le nom et l’identifiant du build ou de l’Archive concernés, tels qu’ils apparaissent dans votre projet et dans App Store Connect.
- L’heure de la tentative et le statut final visible dans la plateforme.
- Le journal de compilation et d’archivage, ainsi que la commande ou le travail d’automatisation qui a généré l’Archive.
- Le canal d’envoi utilisé et l’environnement dans lequel le transfert a été lancé.
Vérifier le Xcode et le SDK réellement employés
Si le message mentionne « Unsupported SDK or Xcode », vérifiez l’environnement qui a produit l’Archive plutôt que la liste des versions installées. Une machine peut contenir plusieurs installations ou sélectionner une version différente de celle que vous aviez en tête. Une tâche exécutée dans un compte non interactif peut aussi ne pas reprendre la configuration que vous observez dans une session de bureau.
Dans le journal de compilation, recherchez les informations de version émises par les outils et les commandes de construction. Comparez-les avec les métadonnées et le journal de validation de l’Archive. Dans le même contexte d’exécution que celui du travail de publication, xcodebuild -version fournit une vérification complémentaire de la version résolue par le système. Pour vérifier le SDK associé, consultez les paramètres de compilation et les outils invoqués dans le journal, plutôt que de déduire le SDK à partir du seul nom de l’application.
Les informations système publiées par Apple permettent de contrôler les compatibilités documentées entre Xcode, macOS et les SDK. Elles ne constituent toutefois pas, à elles seules, la preuve qu’App Store Connect accepte actuellement une soumission produite par cette version. Appuyez-vous sur la page des exigences système de Xcode pour vérifier les informations de compatibilité publiées, puis confrontez-les au refus réel et au statut de la tentative.
Au 31 octobre 2026, la page des versions Apple indique que Xcode 27.2, numéro de build 27B52, a été publié le 29 octobre 2026. Ces détails doivent être vérifiés sur la fiche de publication de Xcode 27.2, plutôt que repris d’une copie d’écran ou d’un nom de fichier local. Cette publication confirme l’existence et l’identification de la version ; elle ne prouve pas que votre compte App Store Connect accepte chaque soumission créée avec elle.
Comparer les indices avant de modifier le projet
La décision dépend du message de refus et de l’artefact testé. La grille ci-dessous sépare le niveau de preuve des différents indices. Elle ne transforme pas une information système ou un témoignage en garantie de soumission.
| Indice observé | Ce qu’il permet de conclure | Force de l’indice pour décider |
|---|---|---|
| Journal de construction et métadonnées de l’Archive | Quelle version de Xcode et quel SDK ont effectivement servi à produire l’artefact | Élevée pour identifier l’environnement de construction |
| Statut et message de refus dans App Store Connect | À quelle étape le transfert ou le traitement s’est arrêté et quel motif la plateforme affiche | Élevée pour diagnostiquer cette tentative précise |
| Exigences système et notes de version Apple | Quelles informations de compatibilité et de version Apple documente | Moyenne : utile pour le contexte, mais ne confirme pas l’acceptation actuelle d’un envoi |
| Rapport d’un autre développeur | Qu’un cas ressemblant a été signalé dans un contexte particulier | Faible : piste à vérifier, pas confirmation d’un défaut généralisé |
| Acceptation d’un ancien Archive RC | Que cet artefact précis a été accepté à ce moment-là | Faible pour prédire le résultat d’une version finale différente |
Le Release Candidate mérite une vérification séparée. Si un Archive produit avec Xcode 27.2 RC a été accepté, cela ne prouve pas que la version finale Xcode 27.2, qui possède son propre numéro de construction, sera acceptée dans les mêmes conditions. Réciproquement, un refus de la version finale ne permet pas de conclure que tous les builds produits avec cette version échoueront : l’artefact, l’environnement, le canal ou l’état de la plateforme peuvent différer.
Apple publie aussi les changements d’App Store Connect dans ses notes de version de la plateforme. Consultez-les pour rechercher une évolution documentée, mais ne les assimilez pas à un avis d’acceptation du build. La documentation Apple sur l’envoi de builds vers App Store Connect décrit le parcours d’envoi ; pour savoir si votre build a été accepté, vérifiez son état réel dans la plateforme.
Réduire le périmètre sans appliquer de faux correctif
Utilisez ces branches pour choisir la prochaine action. Si les conditions ne sont pas réunies, revenez à la chaîne déjà validée au lieu d’accumuler des changements qui brouilleraient le diagnostic.
- Si le message nomme explicitement le SDK ou Xcode et que le journal confirme la version attendue, conservez les journaux, comparez les informations Apple et suspendez les nouveaux essais identiques. Si la plateforme continue de refuser la version finale, utilisez temporairement le Xcode de publication dont l’acceptation a déjà été vérifiée.
- Si le journal montre une autre version que prévu, corrigez d’abord la sélection d’outil dans le script, le compte ou le processus d’automatisation. Ne régénérez l’Archive qu’après avoir confirmé que le travail appelle la version voulue.
- Si l’Archive ne se crée pas, traitez le problème comme un échec de compilation ou de signature, et non comme un refus de chargement. Examinez les erreurs initiales du journal avant de toucher aux paramètres de distribution.
- Si le transfert aboutit mais que le traitement échoue, relevez le statut de traitement et le message correspondant dans App Store Connect. Ne concluez pas qu’un refus de compatibilité du Xcode est en cause si la plateforme affiche un autre motif.
- Si le message concerne l’examen de l’app, suivez les détails de l’examen et les règles qui y sont mentionnées. Un rejet après examen ne prouve pas que le SDK ou l’outil de compilation est refusé.
Si vous devez tester un nouvel envoi, assurez-vous d’abord qu’il répond à une hypothèse claire : par exemple, l’Archive précédent avait été créé par une version différente de celle attendue. Gardez les paramètres de signature et le canal constants lorsque vous cherchez à isoler un problème de version. Si vous changez simultanément de Xcode, de certificat, de script et de méthode de transfert, un résultat positif ne vous dira pas quel changement a résolu le refus.
Revenir à une chaîne validée puis qualifier le retour à Xcode 27.2
Lorsque plusieurs applications partagent le même environnement, évitez de basculer toutes les chaînes de publication en une seule fois. Conservez la dernière configuration dont l’envoi a été accepté, identifiez les projets concernés, puis choisissez un projet représentatif pour vérifier le retour à la nouvelle version. Cette approche limite le risque qu’une mise à niveau non qualifiée bloque des publications sans rapport avec le refus observé.
L’acceptation du build et son approbation après examen sont deux résultats distincts. Après une reprise, consignez séparément la création de l’Archive, la signature, l’acceptation du transfert, le traitement et, le cas échéant, l’issue de l’examen. Le guide Apple de téléversement des builds explique le processus d’envoi ; l’état affiché dans App Store Connect reste la référence pour la tentative de votre compte.
Pour établir un retour maîtrisé, préparez une validation reproductible :
- Sélectionnez un projet représentatif, avec ses dépendances et ses paramètres de distribution habituels.
- Fixez la version de Xcode attendue dans le script et relevez la version réellement résolue au lancement.
- Produisez un nouvel Archive, puis conservez le journal qui associe l’artefact au Xcode et au SDK utilisés.
- Vérifiez le résultat de la signature et démarrez un seul envoi de contrôle avec le canal que vous comptez utiliser en production.
- Attendez un statut explicite dans App Store Connect et archivez le message correspondant, y compris en cas de refus.
- Ne réactivez la chaîne pour les autres projets qu’après avoir confirmé les étapes pertinentes pour votre flux : envoi accepté, traitement terminé et, si nécessaire, disponibilité pour l’examen ou les tests.
Sur un Mac distant, la vérification doit porter sur le processus qui lance réellement la publication, pas uniquement sur une session ouverte manuellement. Dans le même compte et le même contexte que la tâche, relevez la version affichée par xcodebuild -version, le chemin de l’outil sélectionné et le journal de l’Archive. Associez ces traces à l’identifiant du build et au statut d’envoi visible dans App Store Connect. Cette méthode permet de savoir si un script distant appelle une autre installation que celle que vous contrôlez à l’écran.
FAQ sur le refus d’envoi avec Xcode 27.2
Interpréter « Unsupported SDK or Xcode »
Commencez par le texte intégral du refus, puis contrôlez la version de Xcode et le SDK dans les journaux du travail qui a créé l’Archive. La version installée sur le Mac ne suffit pas à établir la version appelée. Si le motif vise l’outil de chaîne, confrontez-le aux informations Apple et au statut App Store Connect avant de modifier le code ou les certificats.
Distinguer la version finale du Release Candidate
Un Archive créé avec Xcode 27.2 RC est un artefact différent de celui produit avec la version finale. Son acceptation antérieure ne garantit donc pas celle de la version finale. Comparez les numéros de construction, les journaux et les résultats d’envoi, et traitez les témoignages d’autres développeurs comme des indices, non comme une confirmation générale d’Apple.
Décider s’il faut renvoyer le même Archive
Si App Store Connect refuse explicitement l’Archive pour la version de Xcode ou le SDK, renvoyer le même fichier sans changement ne répond pas au motif indiqué. Vérifiez d’abord que l’artefact, le canal et l’environnement sont identiques. En l’absence d’une nouvelle information ou d’une correction vérifiable, conservez les preuves et reprenez temporairement la chaîne déjà acceptée.
Identifier le Xcode utilisé sur un Mac distant
Contrôlez le journal de la tâche distante, les métadonnées de l’Archive et la version affichée par xcodebuild -version dans le contexte exact du processus. Une session interactive peut sélectionner une autre installation ou un autre compte que le script de publication. Reliez la version constatée à l’Archive envoyé, puis comparez son identifiant au statut retourné par App Store Connect.
Si votre environnement local ne permet pas de reproduire l’envoi, un Mac distant peut fournir un environnement macOS distinct pour vérifier la chaîne de construction et conserver les journaux. En revanche, si vous disposez déjà d’un Mac stable et que vos publications ne nécessitent aucun environnement séparé, changer de machine ne résoudra pas à lui seul un refus de version. Avant de louer un Mac, vérifiez que votre workflow peut y exécuter les outils nécessaires et que vous pourrez recueillir les éléments de preuve décrits ici ; la décision doit répondre à un besoin de reproduction ou de disponibilité, pas à la seule présence d’un rapport isolé.
Dernière vérification : 31 octobre 2026. Les informations de version et de publication sont à contrôler dans les versions publiées par Apple et les exigences système de Xcode ; l’acceptation doit être confirmée par le message et le statut affichés dans votre App Store Connect.