Checklist de soumission App Store (2026) : du build Xcode 26 jusqu'à Submit for Review

Une checklist de soumission App Store est la liste de tout ce qui doit être prêt en même temps avant de soumettre : un build fonctionnel, une fiche exacte, des réponses honnêtes sur la confidentialité et assez de contexte pour qu'un reviewer puisse utiliser votre app. Un build qui passe au vert ne suffit pas. Les six sections ci-dessous suivent l'ordre dans lequel App Store Connect vous demande ces éléments, et chacune commence par une réponse courte sur laquelle vous pouvez agir.

De quoi une soumission App Store a-t-elle besoin avant de cliquer sur Submit ?

Une soumission App Store nécessite un build traité associé à la version, les métadonnées obligatoires de la version, des captures d'écran, une politique de confidentialité, les coordonnées de contact pour App Review et, si l'app comporte une connexion, des identifiants de démo qui fonctionnent. La liste « Before You Submit » d'Apple dans les App Review Guidelines ajoute deux points : « Activez les services backend pour qu'ils soient en ligne et accessibles pendant la review » et expliquez les fonctionnalités peu évidentes dans les notes de review.

Quels réglages du compte et de la fiche de l'app doivent être prêts ?

Il vous faut une adhésion Apple Developer active, une fiche d'app dont le bundle ID correspond à votre build signé, et une personne de l'équipe ayant le rôle Account Holder, Admin ou App Manager. Ce sont les rôles exigés pour soumettre par la page Submit an app d'Apple.

Lors de la création de la fiche, choisissez le nom, la langue principale et le SKU. Le SKU est interne et les clients ne le voient jamais. Si vous vendez une app payante ou des achats intégrés, finalisez d'abord les contrats pour apps payantes ainsi que les informations fiscales et bancaires. Un contrat non signé peut bloquer un lancement commercial même quand le build est en ordre.

Quelles exigences de build s'appliquent aux envois sur l'App Store en 2026 ?

En octobre 2026, la page upcoming requirements d'Apple indique que « les apps envoyées vers App Store Connect doivent être compilées avec Xcode 26 ou une version ultérieure, avec un SDK pour iOS 26, iPadOS 26, tvOS 26, visionOS 26 ou watchOS 26 » (depuis le 28 avril 2026). Elle précise aussi que les apps iOS et iPadOS « doivent cibler iOS 13 ou une version ultérieure » (depuis le 9 septembre 2026).

• Incrémentez le numéro de build à chaque envoi, et vérifiez que le numéro de version correspond bien à la version que vous comptez publier.
• Mettez à jour l'image Xcode dans votre CI (Codemagic, Expo EAS, GitHub Actions, etc.) en plus de votre propre machine.
• Après le traitement, répondez à l'éventuelle question sur la conformité à l'export et associez le build traité à la version.
• Installez le build TestFlight sur un appareil physique. Testez l'onboarding, la connexion, les états hors ligne, les achats et la restauration des achats. Un essai réussi dans le simulateur ne prouve pas que le build distribué fonctionne.
• Lisez l'e-mail qu'App Store Connect envoie après l'envoi. Les avertissements ITMS concernant les privacy manifests ou les versions de SDK deviennent bloquants si vous les ignorez.

La règle 2.1(a) est sans détour sur ce qui se passe sinon : « Nous rejetterons les bundles et binaires d'app incomplets, ainsi que ceux qui plantent ou présentent des problèmes techniques évidents. » Supprimez les écrans provisoires, les menus de debug et les liens morts avant de faire l'archive. Notre plan de test du build de release pour la règle 2.1 détaille ces vérifications.

Quelles captures d'écran et métadonnées App Store Connect exige-t-il ?

En octobre 2026, les spécifications de captures d'écran d'Apple exigent au moins une capture pour « iPhone with Dynamic Island (medium display) », par exemple 1206 × 2622 ou 1179 × 2556 en portrait. Les apps qui fonctionnent sur iPad ont aussi besoin d'au moins une capture iPad 13 pouces, par exemple 2064 × 2752 ou 2048 × 2732.

Vous « pouvez envoyer jusqu'à 10 captures d'écran par taille d'appareil aux formats .jpeg, .jpg ou .png », et « les images ne peuvent pas contenir de canal alpha ni de transparence ». Si votre interface est identique d'une taille à l'autre, envoyez uniquement la plus haute résolution requise et App Store Connect la réduit automatiquement. La règle 2.3.3 indique que les captures d'écran « doivent montrer l'app en cours d'utilisation, et pas seulement l'écran titre, la page de connexion ou l'écran de démarrage ».

• Rédigez une description qui dit à qui s'adresse l'app et ce qu'on peut y faire dès la première session.
• Gardez un nom, un sous-titre et des mots-clés pertinents. Ne répétez pas les mots-clés et n'utilisez pas de noms de concurrents.
• Vérifiez que l'URL d'assistance et l'URL de la politique de confidentialité se chargent sans connexion.
• Répondez au questionnaire de classification par âge en fonction de ce que l'app contient et permet réellement.
• Montrez le build actuel dans les captures d'écran, y compris tout paywall sur lequel l'utilisateur tombera.

Comment faire correspondre les réponses sur la confidentialité à l'app ?

Pour que vos réponses sur la confidentialité correspondent à l'app, listez chaque SDK que vous embarquez et les données qu'il collecte, puis servez-vous de cette liste pour remplir App Privacy, rédiger la politique de confidentialité et configurer le comportement dans l'app. La règle 2.3 indique que vos métadonnées, « y compris les informations de confidentialité », doivent refléter fidèlement l'app.

La règle 5.1.1(i) précise : « Toutes les apps doivent inclure un lien vers leur politique de confidentialité dans le champ de métadonnées d'App Store Connect et dans l'app, à un endroit facilement accessible. » La règle 5.1.1(v) ajoute : « Si votre app permet de créer un compte, vous devez aussi proposer la suppression du compte dans l'app. » Les SDK d'analytics, de suivi des crashs, de publicité et de connexion modifient généralement vos réponses : auditez-les avec notre audit des SDK pour les privacy labels. Vérifiez aussi que votre app et chaque SDK embarqué incluent un privacy manifest PrivacyInfo.xcprivacy couvrant les API à motif obligatoire (required-reason APIs) qu'ils utilisent.

Que doit contenir App Review Information ?

App Review Information doit indiquer un contact qui répondra, des identifiants de démo qui fonctionnent et n'expirent pas, et des notes qui mènent le reviewer directement à vos fonctionnalités principales. La règle 2.1(a) vous demande d'« inclure les informations d'un compte de démo (et d'activer votre service backend !) si votre app comporte une connexion » ; un mode démo intégré à la place d'un compte nécessite l'accord préalable d'Apple.

Voici un exemple concret de notes de review : « Connectez-vous avec le compte de review fourni. Ouvrez Library, choisissez le projet d'exemple et touchez Export. Toutes les fonctionnalités premium sont débloquées sur ce compte. Les fonctionnalités de localisation utilisent une ville simulée, aucun déplacement n'est donc nécessaire. » N'envoyez pas les reviewers vers un compte vide, un code à usage unique qui expire, ou un parcours qui ne fonctionne que si vous êtes en ligne pour l'approuver. Notre guide de configuration du compte de démo montre comment créer une connexion pour le reviewer qui tienne la route.

Comment soumettre une app pour review dans App Store Connect ?

Pour soumettre une app pour review, associez le build à la version, cliquez sur Add for Review, puis sur Submit for Review. Add for Review seul n'envoie rien à Apple. La séquence ci-dessous suit la page Submit an app d'Apple en octobre 2026.

1. Dans Apps, sélectionnez l'app, puis cliquez sur la version de l'app dans la barre latérale.
2. Faites défiler jusqu'à la section Build et vérifiez que le bon build est associé.
3. Dans la section App Store Version Release, choisissez la publication manuelle si vous voulez maîtriser la date de lancement, puis cliquez sur Save.
4. Cliquez sur Add for Review et choisissez un brouillon de soumission existant ou créez-en un nouveau. Le statut passe à Ready for Review.
5. Cliquez sur Submit for Review. Quand la review commence, le statut passe à In Review.
6. Conservez une copie des métadonnées et des notes soumises, et surveillez l'adresse e-mail de contact pour la review au cas où des questions arriveraient.

Si la soumission est rejetée, lisez le numéro de la règle et l'explication du reviewer avant de modifier quoi que ce soit. Certaines corrections ne concernent que les métadonnées. D'autres nécessitent un nouveau build. Notre guide sur les rejets App Store explique comment savoir dans quel cas vous êtes.

Qu'est-ce qui a coincé pour d'autres développeurs lors de la soumission ?

Dans les deux cas publics ci-dessous, l'app fonctionnait chez son développeur, et le problème n'est apparu que dans le build envoyé ou lors de la première session du reviewer.

Un développeur sur le forum Adalo a reçu un rejet au titre de la règle 2.1 : « we were unable to sign in with the demo account credentials you provided. » Les identifiants étaient valides, mais le premier appui sur le bouton de connexion ne faisait rien et seul un second appui fonctionnait, car une navigation conditionnelle s'exécutait sur le bouton de connexion avant que la session utilisateur soit enregistrée. Il a corrigé le problème en redirigeant le bouton de connexion vers un écran de transition vide qui portait les actions conditionnelles, puis a soumis à nouveau.

Un développeur sur le forum JUCE a reçu « ITMS-91053: Missing API declaration » après un envoi, indiquant que les nouveaux envois « must include a NSPrivacyAccessedAPITypes array in your app's privacy manifest. » Les catégories signalées étaient SystemBootTime et FileTimestamp, et un autre utilisateur a signalé UserDefaults. La solution a été d'ajouter comme ressource Xcode un fichier PrivacyInfo.xcprivacy contenant des codes de motif approuvés. La première version de l'un des utilisateurs omettait une clé de type, ce qui a déclenché ITMS-91056 pour manifest invalide jusqu'à ce qu'il la corrige.

Les deux développeurs n'avaient testé que sur leur propre configuration. Testez le build qu'Apple reçoit réellement avec une connexion vierge, et lisez chaque e-mail reçu après l'envoi, avant de cliquer sur Submit for Review. Si vous souhaitez un regard extérieur sur votre dossier, découvrez nos services de soumission.