Erreurs App Store Connect : ce qu’elles signifient et comment les corriger (2026)

La plupart des erreurs App Store Connect se rangent en trois familles. Les erreurs d’envoi (Xcode ou Transporter refuse le build) viennent du projet lui-même : identifiant de bundle, numéro de version ou de build, SDK ou icône. Les e-mails reçus après l’envoi, comme ITMS-90683, ITMS-91053 et ITMS-91061, signalent un texte d’autorisation ou un manifeste de confidentialité manquant, dans votre code ou dans un SDK. Les messages affichés dans App Store Connect, comme « Missing Compliance » ou « Unable to Submit for Review », se corrigent dans App Store Connect, sans nouveau build. Repérez où le message est apparu, retrouvez son code ci-dessous, appliquez la correction, et n’envoyez un nouveau build que si le binaire doit changer.

Points clés

• Chaque envoi exige un numéro de build jamais utilisé pour cette version, et un numéro de version supérieur à la dernière version approuvée.
• Depuis le 28 avril 2026, les builds envoyés doivent être compilés avec Xcode 26 ou ultérieur et un SDK iOS 26 (ITMS-90725).
• ITMS-90683, ITMS-91053 et ITMS-91061 viennent souvent d’un SDK tiers, pas de votre code ; l’e-mail indique le fichier à examiner.
• « Missing Compliance » et « Unable to Submit for Review » sont des états d’App Store Connect : répondez à la question ou complétez la soumission, sans nouveau build.
• Un refus au titre de la règle 2.1 arrive avec des rapports de plantage : symbolisez-les, reproduisez sur un appareil, puis soumettez un build corrigé.

Tableau récapitulatif : erreur, cause, solution

Où apparaît chaque erreur

Entre Xcode et l’App Store, un build franchit plusieurs étapes de contrôle, chacune avec ses propres messages. L’étape qui a échoué indique où se trouve la correction : dans le projet Xcode, dans un SDK ou dans App Store Connect.

Erreurs à l’envoi du build

Elles s’affichent dans l’Organizer d’Xcode, dans Transporter ou dans les journaux de votre CI, et le build n’atteint jamais App Store Connect. La correction se fait dans le projet, suivie d’une nouvelle archive.

No suitable application records were found. Verify your bundle identifier ‘…’ is correct.

Ce que cela signifie : App Store Connect ne trouve aucune fiche d’app correspondant à l’identifiant de bundle du build envoyé, ou aucune que votre compte peut voir. La page Add a new app d’Apple (en anglais) fixe l’ordre : créez la fiche de l’app avant d’envoyer un build, avec le rôle titulaire du compte, administrateur ou gestionnaire d’app. La documentation Preparing your app for distribution précise que l’identifiant saisi dans App Store Connect doit correspondre à celui du projet, et qu’il ne peut plus changer après le premier envoi.

1. Comparez l’identifiant de bundle dans Xcode (cible › Signing & Capabilities) avec celui de la fiche, y compris les majuscules.
2. Si la fiche n’existe pas, créez-la dans Apps › New App avec cet identifiant.
3. Si elle existe, vérifiez dans Users and Access que le compte qui envoie le build a accès à cette app. Dans un fil des forums Apple Developer, plusieurs développeurs ont réglé le problème en donnant à cet utilisateur l’accès à toutes les apps ou un rôle plus large.

ITMS-90189: Redundant Binary Upload

Ce que cela signifie : le message complet indique « You’ve already uploaded a build with build number ‘…’ for version number ‘…’. Make sure you increment the build string before you upload your app to App Store Connect. » Le numéro de build (CFBundleVersion) doit être nouveau à chaque envoi d’une même version, même si l’envoi précédent a échoué au traitement ou n’est jamais apparu dans TestFlight.

Solution : augmentez le numéro de build (Build, dans l’onglet General de la cible), archivez et renvoyez. Le guide de distribution d’Apple précise qu’Xcode peut l’incrémenter pour vous lors d’un envoi depuis l’Organizer (option « Manage version and build number »). En CI, dérivez-le du numéro d’exécution du pipeline pour qu’il ne se répète jamais. Notre guide TestFlight détaille le reste du parcours d’envoi.

ITMS-90062: This bundle is invalid / ITMS-90186: Invalid Pre-Release Train

Ce que cela signifie : les deux arrivent généralement ensemble. ITMS-90062 indique « The value for key CFBundleShortVersionString […] in the Info.plist file must contain a higher version than that of the previously approved version […] », et ITMS-90186 « The train version ‘…’ is closed for new build submissions ». Vous envoyez un build pour un numéro de version déjà approuvé, ou inférieur à la version approuvée.

Solution : passez le numéro de version (Version dans l’onglet General, CFBundleShortVersionString) au-dessus de la dernière version approuvée, par exemple 2.4 si la 2.3 est en ligne, avec un numéro de build encore inutilisé pour cette version. Apple recommande d’incrémenter le numéro de version à chaque nouvelle version de l’app ; ajoutez la version correspondante dans App Store Connect au moment de la soumettre. « This bundle is invalid » est un préfixe générique : lisez la suite du message, car d’autres erreurs de validation commencent de la même façon.

ITMS-90725: SDK version issue

Ce que cela signifie : le build a été compilé avec un SDK plus ancien que le minimum accepté par Apple. Des développeurs citent des messages comme « This app was built with the iOS 18.2 SDK. Starting April 2026, all iOS and iPadOS apps must be built with the iOS 26 SDK or later, included in Xcode 26 or later ». La page Upcoming Requirements d’Apple confirme que depuis le 28 avril 2026, les apps envoyées sur App Store Connect doivent être compilées avec Xcode 26 ou ultérieur et un SDK iOS 26, iPadOS 26, tvOS 26, visionOS 26 ou watchOS 26.

Solution : compilez avec Xcode 26 ou ultérieur. Le piège habituel, c’est la CI : lancez xcodebuild -version dans le pipeline et mettez à jour l’image de la machine de build. Les builds Flutter et React Native utilisent eux aussi l’Xcode de cette machine. La cible de déploiement est un réglage distinct : depuis le 9 septembre 2026, les builds doivent cibler iOS 13 ou ultérieur, ce que vous pouvez conserver en compilant avec le SDK iOS 26.

ITMS-90717: Invalid App Store Icon

Ce que cela signifie : la grande icône du catalogue de ressources « can’t be transparent nor contain an alpha channel » (ne peut être ni transparente ni contenir de couche alpha). Avec des icônes créées dans Icon Composer, des développeurs ont signalé une variante, « Invalid large app icon », avec la même explication et un lien vers les recommandations d’Apple sur les icônes. Un PNG peut contenir une couche alpha même quand tous ses pixels semblent opaques, d’où la surprise.

Solution : exportez de nouveau l’icône 1024 × 1024 sans transparence, puis vérifiez le fichier avant d’archiver :

# "hasAlpha: yes" : l'icône sera refusée
sips -g hasAlpha AppIcon-1024.png

Si votre icône vient d’Icon Composer et que l’erreur persiste, consultez les notes de version TestFlight d’Apple et le fil des forums consacré à ce message : un ingénieur d’Apple y relie certains cas à l’environnement de build (CI ou machines virtuelles) plutôt qu’à l’icône elle-même.

Erreurs reçues par e-mail après l’envoi

L’envoi réussit, puis App Store Connect analyse le binaire et vous écrit pour signaler les problèmes trouvés. Chaque e-mail nomme le bundle ou le fichier concerné : si le chemin pointe dans Frameworks/, la cause est un SDK. Les trois se corrigent dans le binaire : il faut donc un nouveau numéro de build et un nouvel envoi.

ITMS-90683: Missing purpose string in Info.plist

Ce que cela signifie : le code de l’app fait référence à des API qui accèdent à des données sensibles (appareil photo, localisation, contacts, photos…), ou l’app dispose d’un entitlement qui le permet, mais Info.plist ne contient pas la description d’usage correspondante, par exemple NSCameraUsageDescription. Le message prévient que des SDK peuvent faire référence à ces API, et que le texte reste obligatoire même si votre app ne les appelle jamais.

1. Notez la clé citée dans l’e-mail.
2. Ajoutez-la dans l’onglet Info de la cible (ou dans Info.plist) avec une phrase qui explique clairement pourquoi l’app a besoin de ces données, comme le décrit Requesting access to protected resources.
3. Si vous n’utilisez pas la fonction, trouvez le SDK qui y fait référence : retirez-le s’il ne sert pas, sinon gardez un texte exact.

<key>NSCameraUsageDescription</key>
<string>Photographiez un justificatif pour le joindre à une note de frais.</string>

La règle 5.1.1 demande que ces textes décrivent clairement et complètement l’usage des données : écrivez le vrai cas d’usage plutôt que « Cette app a besoin de l’appareil photo ». Notre checklist de soumission App Store consacre une partie aux textes des demandes d’autorisation.

ITMS-91053: Missing API declaration

Ce que cela signifie : le code du fichier cité utilise une API « à motif obligatoire » (horodatage des fichiers, heure de démarrage du système, espace disque, claviers actifs ou UserDefaults) sans déclarer de motif approuvé dans un manifeste de confidentialité. La documentation d’Apple sur ces API indique que depuis le 1er mai 2024, App Store Connect refuse les apps qui ne décrivent pas leur usage de ces API dans leur manifeste.

Solution : si le chemin désigne l’exécutable de votre app, ajoutez la catégorie et le code de motif correspondant au PrivacyInfo.xcprivacy de l’app. S’il s’agit d’un SDK, mettez ce SDK à jour : chaque SDK doit déclarer son propre usage dans son propre manifeste. Notre guide du manifeste de confidentialité iOS liste les catégories, les codes de motif et la correction pas à pas.

ITMS-91061: Missing privacy manifest

Ce que cela signifie : le build contient un SDK qui figure sur la liste des SDK tiers courants établie par Apple, et cette copie du SDK n’a pas de manifeste de confidentialité. La page third-party SDK requirements d’Apple exige ce manifeste quand vous soumettez une nouvelle app qui contient un SDK de la liste, ou une mise à jour qui en ajoute un, ainsi qu’une signature lorsque le SDK est une dépendance binaire. L’e-mail vous invite à obtenir une version à jour auprès de l’éditeur du SDK.

Solution : mettez le SDK cité à jour vers une version qui embarque un manifeste (et vérifiez laquelle de vos dépendances bloque une ancienne version). Si le SDK est abandonné, remplacez-le. Copier un manifeste dans le framework d’un tiers est une astuce de forum, pas une recommandation d’Apple.

Messages dans App Store Connect

Ces deux messages bloquent le test ou la soumission, mais le build lui-même est correct. La correction se fait dans App Store Connect.

Missing Compliance

Ce que cela signifie : l’usage du chiffrement n’a pas été déclaré pour ce build, qui ne peut donc pas être testé. La page d’aide d’Apple sur la conformité à l’exportation des builds bêta (en anglais) demande de déclarer l’usage du chiffrement pour chaque build afin d’éviter ce statut.

1. Dans App Store Connect, ouvrez l’onglet TestFlight de l’app, sélectionnez le build et cliquez sur « Provide Export Compliance Information » (rôle titulaire du compte, administrateur ou gestionnaire d’app).
2. Répondez aux questions. Si des documents sont exigés, importez-les ; sinon, cliquez sur « Save ».
3. Pour ne plus avoir la question aux builds suivants, ajoutez ITSAppUsesNonExemptEncryption à Info.plist : NO uniquement si l’app, bibliothèques comprises, n’utilise aucun chiffrement ou seulement un chiffrement exempté (comme le HTTPS fourni par le système), YES sinon.

Notre guide TestFlight explique quels usages du chiffrement sont exemptés.

Unable to Submit for Review : « New subscription groups must be submitted with an auto-renewable subscription from within that group »

Ce que cela signifie : la soumission en brouillon contient un nouveau groupe d’abonnements, mais aucun de ses abonnements. L’aide d’App Store Connect précise que le premier groupe d’abonnements doit être soumis avec une nouvelle version de l’app et inclure un abonnement à renouvellement automatique dans la même soumission. Ajouter le groupe n’ajoute pas les abonnements qu’il contient.

Solution : complétez chaque abonnement (durée, prix, nom et description localisés, capture pour App Review), cliquez sur « Add for Review » pour chacun, vérifiez que la version de l’app figure dans le même brouillon, puis soumettez. « Unable to Submit for Review » est un intitulé général qui peut couvrir d’autres motifs : lisez chaque ligne en dessous. La marche à suivre complète, avec les pistes si l’erreur persiste, se trouve dans notre guide pour faire valider ses abonnements par App Review.

Quand App Review refuse le build

Guideline 2.1 – Performance – App Completeness

Ce que cela signifie : la règle 2.1 exige des builds finalisés et testés, et précise qu’Apple refuse les apps incomplètes et les binaires qui plantent ou présentent des problèmes techniques évidents. Les refus rapportés par les développeurs ressemblent à « We were unable to review your app as it crashed on launch », avec les rapports de plantage en pièce jointe. La même règle couvre une connexion sans compte de démonstration, un serveur éteint et des achats intégrés que l’examinateur ne trouve pas.

1. Téléchargez les rapports de plantage joints et symbolisez-les dans Xcode, comme l’explique Diagnosing issues using crash reports and device logs.
2. Reproduisez sur un vrai appareil, avec une installation propre d’un build de production, sur le type d’appareil et la version d’iOS cités dans le message. Un build TestFlight est ce qui se rapproche le plus de ce qu’installe l’examinateur.
3. Cherchez ce qui diffère pour l’examinateur : pas de compte, pas de données, une autre région, une autorisation refusée.
4. Corrigez, incrémentez le numéro de build et soumettez de nouveau, avec une courte note dans App Review sur ce qui a changé.

Si le refus cite plutôt « Guideline 4.2 – Design – Minimum Functionality » ou la règle 4.3 (spam), il porte sur ce que l’app propose, pas sur un plantage : lisez notre guide sur les refus au titre des règles 4.2 et 4.3. Pour la liste complète de ce que vérifie l’examinateur, suivez la checklist de soumission App Store ; pour les captures d’écran, le guide des tailles de captures.

Comment trier n’importe quelle erreur App Store Connect

Les codes changent chaque année, la méthode de tri non. Commencez par une seule question : où le message est-il apparu ?

1. Envoi refusé : corrigez le projet, archivez de nouveau.
2. E-mail après l’envoi : corrigez Info.plist, le manifeste de confidentialité ou le SDK cité, puis renvoyez avec un nouveau numéro de build.
3. Message dans App Store Connect : complétez ce qui est demandé. Pas de nouveau build.
4. Message d’App Review : répondez dans App Store Connect pour un malentendu ou une correction de métadonnées ; soumettez un nouveau build si le binaire doit changer.

Comment Develak aborde les erreurs App Store Connect

Develak publie plus de 30 apps sur l’App Store, et chaque nouvelle version d’Xcode, exigence de SDK ou règle de confidentialité les concerne toutes à la fois. La leçon pratique de ce guide, c’est que la plupart de ces erreurs se préviennent avant l’envoi : placez dès la première version la clé de chiffrement et des textes d’autorisation exacts dans Info.plist, laissez le pipeline de build fixer les numéros de build, comparez les mises à jour de SDK à la liste d’Apple, et relisez la page des exigences à venir d’Apple avant chaque version majeure d’Xcode.

Si l’un de ces messages bloque votre app, ou si vous préférez ne pas suivre vous-même les exigences annuelles d’Apple, notre service de maintenance d’application iOS couvre les mises à jour d’Xcode et des SDK, les manifestes de confidentialité et les soumissions. Seule Apple décide de ce qui est validé, mais aucune de ces erreurs ne devrait bloquer une sortie bien longtemps.

Questions fréquentes