Rejet App Store : les motifs de refus d’Apple en 2026 et comment corriger chacun

La plupart des rejets App Store viennent de soumissions incomplètes ou qui ne marchent pas, pas de règles sur le contenu. La page App Review d’Apple indique que plus de 40 % des problèmes non résolus concernent la guideline 2.1, App Completeness, qui couvre les plantages, le contenu provisoire et les informations incomplètes. Dans le rapport de transparence 2025, la section Performance des guidelines, celle où se trouve la 2.1, est citée dans 1 354 418 rejets, soit davantage que les quatre autres sections réunies.

Après l’app incomplète, les motifs de rejet courants se rangent en quatre familles. Legal regroupe la politique de confidentialité, les demandes d’autorisation, la suppression de compte et la propriété intellectuelle. Design couvre le spam, les copies et les apps aux fonctionnalités trop minces. Business traite des règles d’achat intégré et d’abonnement. Safety porte sur le contenu choquant et le contenu publié par les utilisateurs. Chaque famille correspond à des sections numérotées des App Review Guidelines, et chaque message de rejet cite la guideline sur laquelle il s’appuie.

Ce guide suit donc ces numéros, puisque c’est ce que vous lisez dans le message de rejet : « Guideline 2.1 Performance: App Completeness », « Guideline 4.3(a) Design: Spam », « Guideline 5.1.1(v) Data Collection and Storage ». Pour chacun, vous trouverez le texte d’Apple, les causes habituelles et la correction. Les guidelines ont été mises à jour pour la dernière fois le 16 octobre 2026. Tout ce qui suit a été relu le 4 novembre 2026 dans les App Review Guidelines, qui n’existent qu’en anglais pour cette version, et dans les pages d’aide d’Apple. Les libellés de l’interface sont cités en anglais, comme dans l’aide d’Apple.

Un rejet est rarement définitif. En 2025, Apple a approuvé 387 087 soumissions après un premier rejet. Entre perdre une journée et perdre deux semaines, la différence tient surtout à votre manière de réagir, et c’est l’objet de la seconde moitié de ce guide : lire le message, répondre, soumettre à nouveau, accepter une Bug Fix Submission, faire appel devant l’App Review Board.

« Unable to Add for Review » n’est pas un rejet. App Store Connect l’affiche quand vous cliquez sur Add for Review alors qu’il manque un élément à la soumission : la version n’atteint donc jamais App Review. Sous le titre, la fenêtre indique « The items below are required to start the review process: » puis liste une ligne par élément manquant. La page d’aide Submit an app décrit le parcours normal : vérifier le build, cliquer sur Add for Review, ajouter la version à une soumission en brouillon, puis cliquer sur Submit for Review ; le statut passe à In Review au début de l’examen. Sur les forums d’Apple, des fils plus anciens montrent le même contrôle sous le titre Unable to Submit for Review.

La liste des propriétés obligatoires d’Apple dit ce qui doit être rempli. Au niveau de l’app : nom, bundle ID, SKU, langue principale, catégorie principale, droits sur le contenu, classification par âge et statut au regard du Digital Services Act. Sur la version : URL d’assistance, numéro de version, copyright, informations pour App Review et réglages de publication, plus le texte What’s New pour une mise à jour. Côté prix et disponibilité : la disponibilité et un prix, gratuit compris. Côté confidentialité : l’URL de la politique de confidentialité et vos réponses sur les types de données. La référence des informations de version ajoute les captures d’écran, la description et les mots clés, et chaque version doit avoir un build choisi dans sa section Build.

Le plus souvent, le message nomme l’élément manquant, et le tableau ci-dessous donne la correction pour chaque message signalé par des développeurs. S’il dit seulement « This field is required. » sans rien mettre en évidence, reprenez la liste ci-dessus dans l’ordre. Sur les forums d’Apple, des développeurs ont relié ce message à un champ copyright vide en avril 2021 et à des URL App Store Server Notifications vides en octobre 2021. Seuls les rôles Account Holder, Admin et App Manager peuvent ajouter une version pour examen.

La guideline 2.1(a) demande que chaque soumission soit une version finale, avec toutes les métadonnées nécessaires et des URL qui fonctionnent, débarrassée du texte provisoire, des sites vides et de tout contenu temporaire. Elle demande de tester l’app sur un appareil pour les bugs et la stabilité, et, si l’app comporte une connexion, de fournir un compte de démo et d’allumer votre backend. Elle se termine par la règle à l’origine de la plupart des rejets : Apple rejettera les bundles d’app incomplets et les binaires qui plantent ou présentent des problèmes techniques évidents. Le texte complet se trouve dans les App Review Guidelines.

Les causes sont presque toujours banales. Un plantage sur un appareil ou une version d’iOS que vous n’avez pas testés. Une connexion qui échoue parce que le compte de démo a expiré, ou parce qu’il réclame un code à deux facteurs que personne n’a noté. Un serveur en panne au moment où l’examinateur ouvre l’app. Un lien d’assistance qui pointe vers une page disparue. Une fonction marquée « bientôt disponible ». Aucune n’a de rapport avec le fait qu’Apple aime ou non votre app.

La guideline 2.1(b) porte sur les achats intégrés : ils doivent être complets, visibles pour l’examinateur et fonctionnels, et si un produit configuré est introuvable ou impossible à examiner dans l’app, vous devez expliquer pourquoi dans les notes pour l’examen. Une variante fréquente de ce rejet vient du premier achat. L’aide sur la soumission des achats intégrés précise que le premier achat intégré de chaque type (consommable, non consommable, abonnement à renouvellement automatique, abonnement non renouvelable) doit être soumis avec une nouvelle version de l’app ; une fois le premier d’un type approuvé, les suivants du même type peuvent partir seuls, tant que l’app compte au moins une version approuvée.

La correction, c’est une soumission complète. La page d’Apple sur les informations à fournir pour un examen complet demande, pour une nouvelle app, son concept et son modèle économique ; pour une mise à jour, ce qui a changé et où le trouver. Elle demande aussi les appareils et versions du système testés, les services extérieurs dont l’app dépend, un compte de démo encore valide au début de l’examen, des identifiants pour chaque type de compte, un compte dont l’abonnement a expiré pour que l’examinateur voie le parcours d’achat, et tout code à usage unique dans le champ Notes. Si votre connexion ne peut pas être partagée pour des raisons légales ou de sécurité, la guideline 2.1(a) autorise un mode démo intégré, avec l’accord préalable d’Apple.

« Guideline 2.1 Information Needed » n’est pas tout à fait un rejet. L’examinateur n’a pas pu terminer sans quelque chose de votre part : une connexion qui marche, l’explication d’une fonction, un document, une vidéo de l’app avec son matériel, ou une réponse sur l’origine d’un contenu. L’examen est suspendu jusqu’à votre réponse.

Répondez au message dans App Store Connect, sans soumettre à nouveau. L’aide sur le statut de l’examen indique que lorsque App Review a demandé des informations et qu’il n’y a pas d’autre problème, vous pouvez répondre directement, et qu’une nouvelle soumission lance un nouvel examen après lequel App Review ne peut plus répondre à votre message précédent. Répondez exactement à la question posée, joignez des captures ou un court enregistrement d’écran si cela aide, et mettez à jour les champs App Review Information pour que le prochain examinateur ait les mêmes détails.

Si App Review demande un appel parce que la connexion exige un code, Apple indique que ces appels ont lieu en général sous trois à cinq jours ouvrés, d’après sa page sur l’examen complet. Mettre le code, ou un compte de démo sans code, dans le champ Notes dès le départ évite complètement cette attente.

La section 2.3 couvre tout ce qui apparaît sur la fiche produit. La guideline 2.3.1 exige que chaque nouvelle fonction et chaque changement soient décrits précisément dans les notes pour l’examen (les descriptions génériques sont rejetées), et fait de la promotion trompeuse d’une app, par exemple pour des services qu’elle n’offre pas ou un faux prix, un motif de retrait. La 2.3.2 demande que la description, les captures et les aperçus indiquent clairement ce qui exige un achat supplémentaire. La 2.3.12 demande que le texte What’s New liste les changements importants ; les simples corrections de bugs et améliorations de performance peuvent se contenter d’une formule générique. Pour rédiger ce texte, voyez nos exemples de notes de version.

Les captures d’écran sont le rejet de métadonnées qu’Apple explique le plus en détail. Sa page d’aide sur la guideline 2.3.3 précise que les captures doivent montrer l’app en usage, et pas seulement un visuel de titre, une page de connexion ou un écran de démarrage, et qu’App Review n’approuve le jeu de captures d’un appareil que si plus de la moitié montrent l’app en usage. Avec trois captures, deux doivent montrer l’app ; avec quatre, trois. Les textes et images en surimpression sont permis tant qu’ils n’étouffent pas l’app et ne cachent pas sa fonction principale, et les captures doivent correspondre à l’interface actuelle. Notre guide des tailles de captures d’écran App Store donne les formats exigés par Apple, et notre vérificateur de taille de captures contrôle vos fichiers avant l’envoi.

La guideline 2.3.7 limite le nom de l’app à 30 caractères et interdit de bourrer les métadonnées de marques déposées, de noms d’apps populaires, de prix ou de formules sans rapport ; notre compteur de caractères App Store vérifie ces limites. La 2.3.8 demande que les icônes, captures et aperçus conviennent à une classification 4+ même si l’app est classée plus haut, et réserve des mentions comme « For Kids » à la catégorie Enfants. La 2.3.10 interdit les noms, icônes ou images d’autres plateformes mobiles ou de boutiques d’apps alternatives dans l’app et ses métadonnées. La règle la plus récente, la 2.3.14, ajoutée le 16 octobre 2026, applique les mêmes exigences aux nouveaux visuels créatifs affichés en tête de fiche et dans les résultats de recherche : pas de référence trompeuse à d’autres apps, pas d’affirmation invérifiable, pas de prix précis ni de prix barré.

Le statut Metadata Rejected signifie que seule la fiche produit doit être reprise. La liste des statuts d’Apple dit de lire le message, de modifier les métadonnées pour régler le problème, puis de répondre à App Review. Pas besoin de nouveau build, et l’examen reprend en général vite après votre réponse.

La guideline 2.5.1 précise que les apps ne peuvent utiliser que des API publiques, qu’elles doivent tourner sur le système d’exploitation actuellement distribué et qu’elles doivent abandonner progressivement les frameworks dépréciés. La 2.5.2 exige que les apps soient autonomes et interdit de télécharger, d’installer ou d’exécuter du code qui ajoute ou modifie des fonctions. C’est pour cette raison qu’une app qui charge de nouvelles fonctions depuis un serveur après l’examen est rejetée ou retirée, et que les mini apps, mini jeux, chatbots et extensions relèvent d’une guideline à part, la 4.7.

Apple a ajouté la guideline 2.5.19 le 16 octobre 2026. Elle interdit les fonctions cachées, dormantes ou non documentées, et précise que les dissimuler dans le binaire, par obfuscation du code ou par un autre moyen, justifie le retrait de l’App Store et la résiliation du compte développeur. L’annonce d’Apple sur ce changement désigne la cible sous le nom de bait and switch : des apps qui travestissent leur objet pendant l’examen et révèlent d’autres capacités après l’approbation. La note de mise à jour précise que cette règle figurait jusque-là dans la 2.3.1. Si votre app active des fonctions plus tard par configuration à distance, chaque fonction que l’examinateur pourra atteindre après la sortie doit être présente et décrite dans la version que vous soumettez.

Les exigences de compilation comptent aussi parmi les exigences logicielles, même si elles s’appliquent à l’envoi plutôt qu’à l’examen. Depuis le 28 avril 2026, les apps envoyées sur App Store Connect doivent être compilées avec le SDK iOS 26 ou plus récent, selon l’annonce d’Apple sur les SDK minimums, et à partir d’avril 2027 avec le SDK iOS 27. Un build qui ne respecte pas les exigences en vigueur prend le statut Invalid Binary et demande un nouvel envoi.

La confidentialité est la deuxième source de rejets, et celle dont les règles sont les plus détaillées. La guideline 5.1.1(i) exige que chaque app renvoie vers sa politique de confidentialité à deux endroits : dans le champ prévu des métadonnées d’App Store Connect et dans l’app, à un endroit facile à trouver. La politique doit dire quelles données l’app collecte, comment et pourquoi, confirmer que tout tiers qui reçoit ces données leur assure une protection équivalente, et expliquer la conservation, la suppression et la manière de retirer son consentement.

La 5.1.1(ii) impose le consentement avant toute collecte de données d’utilisateur ou d’usage, même des données jugées anonymes, et interdit qu’une fonction payante dépende de l’accès à ces données. Elle exige aussi des purpose strings, la phrase qu’iOS affiche dans chaque demande d’autorisation, qui décrivent l’usage clairement et complètement. La page d’aide d’Apple sur les purpose strings donne le contraste attendu, que nous traduisons ici : « Pour utiliser la localisation. » ne suffit pas ; « L’app utilise votre position pour calculer l’itinéraire conseillé jusqu’à votre destination et vous guider étape par étape. » est clair. Écrivez une phrase précise par ressource protégée, traduisez-la pour chaque langue que vous prenez en charge, et retirez le code de SDK qui demande une autorisation dont vous n’avez pas besoin.

La 5.1.1(iv) exige que les apps respectent les réglages d’autorisation sans piéger ni forcer les gens vers un accès inutile. L’exemple d’Apple : une app qui publie des photos sur un réseau social mais réclame d’abord le micro. Si quelqu’un refuse la localisation, proposez de saisir une adresse à la main. La 5.1.2(i) ajoute que vous devez indiquer clairement où des données personnelles sont partagées avec des tiers, y compris avec une IA tierce, et obtenir une autorisation explicite avant de le faire. Une app qui envoie le texte ou les photos de ses utilisateurs à un modèle d’IA extérieur doit donc afficher cette information et recueillir ce consentement dans l’app, et pas seulement dans la politique de confidentialité.

Deux exigences techniques provoquent des rejets dès l’envoi. Depuis le 1er mai 2024, les apps qui utilisent des API de la liste des raisons obligatoires d’Apple doivent déclarer une raison approuvée dans un manifeste de confidentialité, selon la mise à jour d’Apple sur la confidentialité des soumissions. Et quand vous ajoutez un SDK de la liste des SDK tiers couramment utilisés, qui compte 86 entrées dont FirebaseCore, Alamofire, Flutter, OneSignal et Lottie, vous devez utiliser une version qui embarque son propre manifeste de confidentialité, signée s’il s’agit d’une dépendance binaire.

La guideline 4.3 est le rejet que les développeurs ont le plus de mal à corriger, parce qu’il vise l’idée et non un bug. Elle a deux volets. La 4.3(a) demande de ne pas créer plusieurs bundle IDs pour la même app. L’exemple d’Apple : une app de carte distincte pour chaque ville du monde au lieu d’une seule carte où l’on cherche n’importe quelle ville. Son conseil : soumettre une seule app et proposer les variantes par lieu, équipe ou université via des achats intégrés.

La 4.3(b) demande de ne pas soumettre d’apps impossibles à distinguer de ce qui existe déjà en abondance. Elle cite des catégories bien installées sur l’App Store, dont les apps de rencontre, les lampes torches, les effets sonores, les fonds d’écran, les minuteurs simples et la voyance, et annonce qu’Apple n’en acceptera pas de nouvelles sans une expérience nettement différente ou meilleure. Les apps créées à partir d’un template commercial ou d’un service de génération d’apps relèvent d’une règle voisine, la 4.2.6 : elles sont rejetées, sauf si le fournisseur du contenu de l’app les soumet lui-même.

Apple a révisé les deux volets le 8 juin 2026, pour préciser le fondement de la guideline et ajouter des exemples. Les témoignages réunis par Michael Tsai relient en partie la hausse des soumissions de 2025 et 2026 aux apps construites vite avec des outils de code par IA, et c’est dans ce contexte que la 4.3 s’applique aujourd’hui.

Ce qui marche, d’après les cas que décrivent les développeurs : changer l’app, pas l’argumentaire. Fusionnez les apps quasi identiques en une seule. Retirez les écrans de template et les visuels génériques. Ajoutez la fonction qui rend l’app différente, puis dites dans les notes pour l’examen, en deux ou trois phrases simples, ce que fait cette app que les alternatives évidentes ne font pas. Une réponse qui se contente d’affirmer que l’app est unique, sans changement dans le build, fait rarement bouger un rejet 4.3. Si plusieurs de vos apps ont été rejetées au titre de la 4.3, prenez-le au sérieux : la 4.3(b) prévient que des soumissions répétées de ce genre peuvent mener au retrait de l’Apple Developer Program, et notre guide du compte développeur Apple explique ce que ce programme engage.

La guideline 4.2 s’ouvre sur une phrase qui explique la plupart de ces rejets : votre app doit offrir des fonctions, du contenu et une interface qui la placent au-dessus d’un site web remis en paquet. Elle poursuit : une app qui n’est pas particulièrement utile, originale ou « digne d’une app » n’a pas sa place sur l’App Store. La 4.2.2 ajoute qu’en dehors des catalogues, une app ne doit pas être d’abord un support marketing, une publicité, un extrait de site web, un agrégateur de contenu ou une collection de liens. La 4.2.3 exige qu’une app fonctionne seule, sans installer une autre app, et qu’elle annonce la taille de tout téléchargement supplémentaire avant de le lancer.

Les apps webview sont le cas d’école. Envelopper un site dans une coque native est permis, mais une app qui affiche le même site sans rien ajouter reçoit en général un rejet 4.2. Même chose pour les utilitaires d’un seul écran qui font une petite chose déjà prévue par iOS, et pour les apps dont le contenu se résume à un livre ou à un guide de jeu, qu’Apple renvoie vers Apple Books.

La correction consiste à donner à l’examinateur une raison d’être de l’app. Servez-vous de ce que le site ne sait pas faire : l’accès hors ligne, les widgets, des notifications que les gens choisissent d’activer, l’appareil photo, Apple Pay, Sign in with Apple, le partage vers d’autres apps, ou des données qui restent sur l’appareil. Rendez l’app utilisable sans connexion quand c’est possible. Puis dites dans les notes pour l’examen ce que fait l’app que le site ne fait pas. Ces pistes sont notre lecture de la guideline et de l’expérience publiée par des développeurs, pas une liste fournie par Apple.

La guideline 4.1 demande de ne pas copier la dernière app à la mode, ni de modifier à peine le nom ou l’interface d’une autre app pour la faire passer pour la vôtre. La 4.1(b) considère l’usurpation d’autres apps ou services comme une violation du code de conduite des développeurs, et la 4.1(c) interdit d’utiliser l’icône, la marque ou le nom de produit d’un autre développeur dans votre icône ou votre nom sans son accord. La page d’aide d’Apple sur les copies liste les déclencheurs habituels : fonctions ou apparence copiées, nom ou icône proches d’une app existante, autres marques dans le titre, le sous-titre ou les mots clés, captures qui ne montrent pas votre vraie app, nom de développeur ou URL d’assistance périmés. Dans chaque cas, la correction consiste à rendre l’app clairement vôtre, ou à obtenir une autorisation écrite et à la joindre.

La guideline 4.8 concerne les apps qui utilisent une connexion tierce ou sociale, comme Google Sign In, Facebook Login, Sign In with LinkedIn ou Log in with X, pour créer le compte principal de l’utilisateur. Ces apps doivent aussi proposer, comme option équivalente, un autre service de connexion qui limite la collecte au nom et à l’adresse email, permet de garder son adresse email privée et ne collecte pas les interactions à des fins publicitaires sans consentement. Sign in with Apple remplit les trois conditions, c’est pourquoi la plupart des développeurs l’ajoutent quand ce rejet arrive, même si la guideline décrit des fonctions sans nommer de service.

L’exigence ne s’applique que lorsqu’une connexion tierce ou sociale crée le compte principal : une app qui n’utilise que sa propre connexion par email et mot de passe n’est pas concernée. Si votre app propose Sign in with Apple, pensez à la règle sur la suppression de compte : supprimer un compte doit aussi révoquer les jetons Sign in with Apple.

La guideline 3.1.1 précise que pour débloquer des fonctions dans une app, comme des abonnements, des monnaies de jeu, des niveaux, du contenu premium ou une version complète, vous devez passer par l’achat intégré, sans mécanisme de déblocage maison comme des clés de licence, des QR codes ou des portefeuilles de cryptomonnaie. C’est le cœur de la section Business, citée dans 283 820 rejets en 2025.

Les abonnements ont leurs propres règles. La 3.1.2(a) exige qu’un abonnement à renouvellement automatique apporte une valeur continue, dure au moins sept jours et soit disponible sur tous les appareils de l’utilisateur. La 3.1.2(c) demande, avant de proposer l’abonnement, de décrire clairement ce que l’on obtient pour ce prix et de communiquer les exigences de l’annexe 2 (Schedule 2) du contrat de licence développeur. Un paywall qui cache le prix, la période de renouvellement ou le contenu de l’abonnement est un rejet Business classique.

Certaines exceptions passent souvent inaperçues. Les apps de lecture visées par la 3.1.3(a), comme les magazines, journaux, livres, musique et vidéo, peuvent donner accès à du contenu acheté ailleurs. Les services multiplateformes de la 3.1.3(b) peuvent débloquer des achats faits sur d’autres plateformes, à condition que ces éléments soient aussi proposés en achat intégré. Et la 3.1.1(a) précise que sur la vitrine des États-Unis, les développeurs n’ont pas besoin d’un entitlement pour ajouter des boutons, des liens externes ou d’autres appels à l’action. Ailleurs, la même guideline décrit les entitlements que les développeurs peuvent demander pour ajouter un lien vers une destination d’achat autorisée.

La plupart des rejets d’achats intégrés sont mécaniques plutôt que liés aux règles : un produit que l’examinateur ne trouve pas, un bouton de restauration des achats qui ne fait rien, un achat qui échoue en sandbox, ou un premier abonnement soumis sans version de l’app. Testez chaque produit en sandbox avec un compte neuf avant de soumettre, et laissez à l’examinateur un compte dont l’abonnement a expiré.

Les rejets Safety formaient le plus petit groupe en 2025, avec 151 159 citations, mais ils sont stricts. La guideline 1.2 exige des apps qui accueillent du contenu d’utilisateurs un moyen de filtrer le contenu choquant, un mécanisme de signalement avec des réponses rapides, la possibilité de bloquer les utilisateurs abusifs et des coordonnées publiées. Si votre app a des commentaires, un chat, des profils, des envois de fichiers ou des avis, ces quatre éléments doivent figurer dans le build que voit l’examinateur.

Apple a retouché la 1.2 trois fois en 2026. Le 6 février 2026, il a précisé que les apps de chat aléatoire ou anonyme relèvent des règles sur le contenu des utilisateurs. Le 8 juin 2026, un nouveau paragraphe a précisé la responsabilité des développeurs pour le contenu qui enfreint la guideline. Le 16 octobre 2026, il a ajouté que la modération couvre désormais explicitement les images intimes diffusées sans consentement, y compris celles produites avec des outils d’IA, et que les développeurs qui ne mettent pas de protections en place, ou ne corrigent pas les violations après un avertissement, risquent le retrait. Les apps qui génèrent ou retouchent des images de personnes par IA doivent traiter la modération comme une condition de sortie.

Le reste de la section Safety couvre le contenu choquant, les apps pour enfants de la catégorie Enfants, les atteintes physiques et les affirmations médicales. Les apps médicales qui pourraient servir à diagnostiquer ou à traiter des patients sont examinées de plus près (1.4.1), et la page d’Apple sur l’examen complet demande, pour celles qui revendiquent un diagnostic ou un traitement, l’autorisation réglementaire de chaque pays ou région où elles sont disponibles. Mettez-la dans les notes pour l’examen avant de soumettre.

On cherche désormais « Apple rejected vibe coded app », et le phénomène est réel, même si Apple n’a aucune règle sur la manière dont une app est écrite. Les apps générées vite avec des outils de code par IA butent souvent sur les mêmes quatre guidelines. Elles ressemblent à beaucoup d’autres apps d’une catégorie encombrée : c’est la 4.3(b). Elles enveloppent une idée simple ou un site web : c’est la 4.2. Elles sortent avec des écrans provisoires, des parcours jamais testés ou un backend éteint : c’est la 2.1. Et elles envoient parfois des données d’utilisateurs à un modèle d’IA sans l’information et le consentement qu’exige la 5.1.2(i).

Le volume en jeu est important. Les témoignages réunis par Michael Tsai citent des données Appfigures selon lesquelles les soumissions sur l’App Store ont augmenté de 24 % en 2025 jusqu’à novembre, et un article de The Information selon lequel les nouvelles apps ont progressé d’environ 30 % en 2025. Apple n’a pas lié ses décisions de rejet à la façon dont une app est construite, et sa règle la plus récente, la 2.5.19 contre les fonctions cachées ou non documentées, s’applique à toutes les apps de la même façon.

Si vous construisez avec des outils d’IA, voyez la soumission comme la partie qu’ils ne font pas à votre place : tester sur un appareil, retirer le contenu de template, rédiger la politique de confidentialité et les demandes d’autorisation, ajouter la suppression de compte s’il y a des comptes, et écrire avec vos propres mots, dans les notes pour l’examen, ce qui rend l’app différente.

Quand une soumission ne passe pas, le statut de la version devient Rejected, ou Metadata Rejected si seule la fiche produit pose problème, et la soumission affiche Unresolved Issues. La liste des statuts indique qu’App Review prévient les utilisateurs d’App Store Connect qui ont le rôle Admin, App Manager ou Developer, et la page pour contacter App Review précise que vous recevez dans App Store Connect un message qui détaille les problèmes à régler. Un spécialiste qui connaît votre app répond ensuite à vos questions au même endroit.

Beaucoup de développeurs parlent encore du Resolution Center. Les pages d’aide actuelles d’Apple parlent de la section App Review d’App Store Connect, et le bouton pour répondre s’appelle Reply to App Review. Apple demande d’être précis sur la fonction, la guideline ou l’étape à clarifier, et de ne pas utiliser ce champ pour faire appel ou demander un examen accéléré, qui ont leurs propres formulaires.

Un rejet ne touche pas la version déjà en ligne sur l’App Store. Votre app actuelle reste disponible pendant que vous corrigez la nouvelle. Seule la version soumise est bloquée, avec les achats intégrés ou autres éléments de la même soumission. Si certains éléments ont été acceptés et d’autres rejetés, Apple conseille de retirer les éléments rejetés et de soumettre à nouveau pour que les autres avancent.

Le temps que tout cela ajoute dépend du chemin choisi, résumé dans le tableau ci-dessous et dans notre guide sur le délai d’examen App Store.

Si vous pensez que l’app respecte les guidelines, vous pouvez faire appel devant l’App Review Board. La page d’aide d’Apple sur l’appel indique qu’un appel se justifie quand une app a été rejetée ou retirée alors que vous pensez qu’elle respecte les App Review Guidelines et le contrat développeur, quand votre compte est menacé de résiliation, ou quand vous estimez avoir été traité de façon injuste ou partiale. Ce n’est pas le canal pour connaître l’état d’un examen ni pour demander un examen accéléré.

La marche à suivre est fixée. Répondez d’abord au rejet dans App Store Connect pour clarifier le problème ; ne faites appel que si cette réponse ne suffit pas. Utilisez ensuite le formulaire Submit an appeal d’Apple, citez les exigences précises en cause et expliquez point par point comment l’app satisfait chacune. Le Board vous écrit dans App Store Connect à la fin de son enquête, et peut demander des informations ou proposer un appel. Déposez un seul appel par app rejetée et traitez toutes les guidelines citées dans ce même appel ; le formulaire accepte jusqu’à cinq apps à la fois. Soumettre l’app à nouveau clôt l’appel.

Apple montre à quoi ressemble un bon appel. Son exemple complet dit, en substance : l’app a été rejetée au titre de la 2.1 pour informations incomplètes, le compte de démo et les étapes de configuration figurent dans App Review Information, et des captures montrent la fonction qui marche. Son exemple incomplet se contente de dire que l’app compte pour l’entreprise et n’aurait pas dû être rejetée. Apple ajoute qu’un appel complet aide le Board à aller vite, mais ne garantit pas que la décision sera annulée.

Apple ne publie pas le taux de succès des appels contre un rejet. Son rapport de transparence 2025 donne à la place les appels contre un retrait d’app : 26 305 appels et 423 apps rétablies, environ 1,6 % d’après notre calcul. Au Royaume-Uni, les engagements d’Apple auprès de la CMA du 30 mars 2026 promettent un appel devant l’App Review Board de plein droit, une explication de la façon dont chaque soumission rejetée enfreint les guidelines, et des chiffres annuels pour les développeurs britanniques sur les appels contre les rejets, les apps approuvées après appel et la part des appels traités en moins de 60 jours, le premier rapport étant attendu au plus tard le 31 mars 2027.

Si une mise à jour d’une app déjà présente sur l’App Store est rejetée pour un problème sans enjeu légal ni de sécurité, Apple peut vous laisser la publier et corriger le problème la fois suivante. La page Bug Fix Submissions d’Apple précise que l’offre apparaît en tête du message de rejet, avec la phrase « Bug Fix Submissions: The issues we've identified below are eligible to be resolved on your next update. »

Pour l’accepter, répondez au message, dites que vous souhaitez l’approbation de la soumission actuelle et que vous traiterez les problèmes dans la prochaine mise à jour, et ne soumettez pas à nouveau, sous peine de relancer un examen. App Review confirme et approuve la soumission. Dans la mise à jour suivante, vous devez régler chaque problème reporté, et un problème déjà reporté une fois ne peut pas l’être de nouveau. Si la mention ne figure pas dans le message, la soumission n’est pas éligible et les problèmes doivent être corrigés d’abord. Pour savoir à quel rythme les apps publient leurs mises à jour, voyez notre étude sur la fréquence des mises à jour d’apps.

Google affiche une vérification anti robot à nos contrôles automatiques : les faits de cette section reprennent la version anglaise de ce guide (mise à jour le 2 novembre 2026) et n’ont pas pu être relus aujourd’hui. Google Play examine les apps selon ses règles du programme pour les développeurs, et sa page sur l’application des règles liste les issues possibles : rejet, retrait, suspension, visibilité ou régions limitées, compte restreint et résiliation. Le message de rejet nomme la règle, et Google envoie par email la marche à suivre pour faire appel si vous pensez qu’il s’est trompé.

Le rejet Google Play sans équivalent sur l’App Store, c’est le formulaire Data safety. L’aide de Google sur la section Data safety précise que chaque app publiée sur Google Play doit le remplir, même si elle ne collecte aucune donnée, que les développeurs sont seuls responsables de déclarations complètes et exactes, et, à la question de savoir si une app peut être bloquée à cause de ce formulaire, répond en bref que oui. Les déclarations inexactes doivent être corrigées, et les apps non conformes peuvent voir leurs mises à jour bloquées ou être retirées.

Deux autres différences comptent pour planifier. Les nouveaux comptes développeur personnels créés après le 13 novembre 2023 doivent mener un test fermé avec au moins 12 testeurs pendant au moins 14 jours avant de demander l’accès à la production, selon les exigences de test de Google. Et l’aide de Google sur les apps retirées accepte un appel par mesure, traité en anglais, en chinois, en coréen ou en japonais. Si vous publiez sur les deux stores, gardez alignés la politique de confidentialité, les réponses App Privacy d’Apple et le formulaire Data safety de Google, parce qu’un écart entre eux est le rejet le plus facile à provoquer d’un côté comme de l’autre.

Certaines de ces règles s’appliquent aussi à la façon dont vous faites connaître l’app. La guideline 2.3.1 prévient que la promotion trompeuse d’une app, sur l’App Store ou ailleurs, par exemple pour des fonctions qu’elle n’a pas ou un faux prix, justifie son retrait. Les règles marketing distinctes d’Apple encadrent l’usage du badge App Store, des appareils Apple et de votre note dans vos publicités et vos posts sur les réseaux sociaux.

Notre guide des règles marketing de l’App Store et du badge les explique sans jargon, et notre page de statistiques App Store suit les chiffres annuels de rejets et de retraits à mesure qu’Apple les publie. Si votre fiche comporte un aperçu vidéo, notre guide sur l’aperçu vidéo App Store reprend la règle 2.3.4, qui n’autorise que des captures vidéo de l’app elle-même.

Passer App Review, c’est la partie difficile d’une mise à jour. L’annoncer ne devrait pas l’être. Spreadcast consulte chaque jour votre fiche App Store publique, repère chaque version approuvée dès sa mise en ligne et la transforme en post mis en page avec votre icône et vos captures d’écran dans un cadre d’iPhone, avec une légende écrite pour chaque réseau. Il publie sur Instagram, Facebook, LinkedIn, Pinterest et vos autres comptes connectés, au rythme que vous fixez. L’interface de Spreadcast est en anglais.

Les posts suivent les règles marketing d’Apple : de vraies captures de l’app actuelle, aucune fonction inventée, aucun prix susceptible de changer. Le même passage quotidien transforme les nouveaux avis 5 étoiles et les paliers de note en posts. Collez votre lien App Store sur la page de démarrage pour voir un post rédigé à partir de votre fiche, et consultez les offres pour la publication automatique.