Rejet App Store : comment le corriger, règle par règle (2026)

Un rejet App Store est un message d'App Review qui cite une règle, décrit ce que l'examinateur a constaté et bloque la publication jusqu'à ce que vous corrigiez, expliquiez ou fassiez appel. Commencez par transformer ce message en un problème que vous pouvez tester. La suite dépend de la situation : l'examinateur n'a pas pu utiliser l'app, il a relevé un écart avec une règle, ou il lui manque des informations. En octobre 2026, les App Review Guidelines ont été mises à jour pour la dernière fois le 16 octobre 2026 : vérifiez donc la numérotation en ligne avant de citer une section.

Que vous apprend vraiment un message de rejet App Store ?

Un message de rejet App Store nomme la règle appliquée par l'examinateur, décrit le comportement précis qu'il a observé et liste les prochaines étapes. Il précise souvent l'appareil, la version d'iOS et joint des captures d'écran.

Conservez le message complet, les captures d'écran, le numéro de build et les détails de l'appareil. Lisez la section citée sur la page des règles en ligne. Puis écrivez une phrase : « L'examinateur n'a pas pu faire X à cause de Y. » Si le message demande des informations manquantes au lieu de signaler un défaut, notez précisément ce qui manque. Le texte standard d'Apple pour la règle 2.1 explique aussi comment reproduire le problème : « Pour les nouvelles apps, désinstallez toutes les versions précédentes de votre app d'un appareil, puis installez-la et suivez les étapes pour reproduire le problème. »

• Le message mentionne-t-il un crash, un écran inaccessible ou une fonctionnalité incomplète ? Reproduisez ce parcours dans le build de release soumis, sur le type d'appareil indiqué par Apple.
• Mentionne-t-il les captures d'écran, la description ou les notes pour l'examen ? Vérifiez si une correction des seules métadonnées suffit.
• Mentionne-t-il les paiements, la connexion, la confidentialité ou la fonctionnalité minimale ? Comparez le comportement du produit avec la règle citée.

Quelles règles les rejets App Store citent-ils, et qu'exigent-elles ?

Chaque règle fixe une exigence concrète : faites correspondre le numéro cité à son texte et testez par rapport à ce texte. Le tableau cite la formulation actuelle des règles que l'on retrouve souvent dans les messages de rejet.

La mise à jour du 16 octobre 2026 a ajouté la règle 2.5.19 pour les fonctionnalités cachées, dormantes ou non documentées, auparavant couvertes par la 2.3.1. Elle a aussi ajouté la 2.3.14 sur les éléments créatifs et intégré l'entitlement Music Streaming Services à l'entitlement StoreKit External Purchase Link, dans la règle 3.1.1(a). Voyez ce tableau comme un point de départ, pas comme une correction garantie. Une même règle peut couvrir des problèmes différents, et l'exemple donné par l'examinateur est le cas concret que vous devez résoudre.

Comment corriger un rejet 4.2 pour fonctionnalité minimale ?

Corrigez un rejet 4.2 en ajoutant une vraie valeur d'app, pas en reformulant la description. La règle 4.2 indique : « Si votre app n'est pas particulièrement utile, unique ou “digne d'une app”, elle n'a pas sa place sur l'App Store. »

Demandez-vous ce qu'un utilisateur peut faire dans votre app qui la rend utile en tant qu'app. Il peut mener un parcours à terme, enregistrer un état qui compte, utiliser les capacités de l'appareil d'une manière cohérente avec l'app, ou profiter d'une expérience mobile conçue pour l'appareil. Aucune liste de fonctionnalités publiée ne garantit l'approbation. Si ces parcours existent déjà, listez-les dans les notes pour l'examen avec les étapes exactes et des captures d'écran. Si l'app affiche surtout une page web, c'est le produit qu'il faut retravailler. Ajouter des notifications ou un écran de réglages vide pour paraître natif ne remplace pas une vraie valeur pour les utilisateurs.

Comment répondre à App Review dans App Store Connect ?

Répondez dans App Store Connect : ouvrez la soumission depuis le lien des problèmes non résolus de l'app, cliquez sur Resolve, puis sur Reply to App Review. Selon la page d'aide d'Apple, il faut le rôle Account Holder, Admin ou App Manager.

1. Dans Apps, sélectionnez l'app.
2. En haut de la page, cliquez sur le lien indiquant qu'il y a des problèmes non résolus.
3. Dans la section In Progress, cliquez sur Resolve à côté de la soumission.
4. Cliquez sur Reply to App Review et saisissez votre texte.
5. Pour inclure des captures d'écran ou des documents, cliquez sur Attach File, puis sur Reply.

Apple précise que vous pouvez échanger et joindre des fichiers « jusqu'à ce que vous soumettiez à nouveau à App Review » : envoyez donc vos preuves avant de soumettre à nouveau. Gardez une réponse courte et factuelle : ce qui a changé, où le trouver et comment le vérifier. N'invoquez pas d'autres apps qui semblent faire la même chose.

Faut-il corriger les métadonnées, envoyer un nouveau build ou faire appel ?

Corrigez les métadonnées et soumettez à nouveau le même build quand seules les informations de la fiche étaient erronées. Envoyez un nouveau build quand le comportement de l'app doit changer. Ne faites appel que si vous estimez que l'app respecte déjà la règle.

Les consignes d'Apple sur les appels vous demandent d'« expliquer point par point comment votre app respecte » la règle. Elles précisent aussi de ne pas faire appel si vous avez déjà corrigé les problèmes et soumis à nouveau. Un appel complet « ne garantit pas » que la décision sera annulée. Pour les apps déjà publiées, la politique Bug Fix Submissions des règles indique que les corrections de bugs ne seront pas retardées pour des violations des règles, « sauf celles liées à des questions juridiques ou de sécurité ».

Comment d'autres développeurs ont-ils corrigé de vrais rejets App Store ?

Dans les discussions publiques des forums, beaucoup de rejets 2.1 venaient d'écarts entre l'environnement de l'examinateur et celui du développeur : un autre réseau, un autre appareil ou un autre état des autorisations. Un rejet 4.2 est un problème de produit, et de petits ajustements suffisent rarement à le lever.

Erreur de connexion sous la règle 2.1. Un développeur sur les Apple Developer Forums a cité le message « Specifically, we were not able to log in due to an error », alors que la version en ligne et la version TestFlight se connectaient avec les mêmes identifiants. D'autres développeurs de la discussion ont rapporté des correctifs différents. L'un l'a résolu en « passant de http à https sur le serveur web ». Un autre, après trois rejets, a ajouté un état « Vérifiez votre connexion » à la place d'un chargement sans fin. Un troisième a retiré l'iPad de la cible de déploiement après cinq rejets, ce qui contourne le problème en abandonnant la prise en charge de l'iPad.

Crash au lancement. Sur le forum Solar2D, un développeur a reçu le message « We were unable to review the app because it crashed on launch » sur un iPhone 13 mini sous iOS 18.3.2. Le journal de crash joint montrait une clé NSUserTrackingUsageDescription manquante. Le développeur a confirmé : « C'est passé après avoir ajouté : NSUserTrackingUsageDescription. »

App WebView sous la règle 4.2. Un développeur sur les Apple Developer Forums a signalé un 10e rejet pour une app basée sur une WebView. L'examinateur avait envoyé une capture du menu de gauche en indiquant qu'il manquait de contenu. Les écrans principaux étaient désormais natifs, mais deux ou trois ouvraient encore une WebView. La réponse marquée comme solution venait d'App Review et recommandait une consultation individuelle avec App Review. La discussion ne confirme pas d'approbation.

La comparaison : les cas 2.1 ont été résolus en reproduisant les conditions de l'examinateur et en lisant le journal de crash. Le cas 4.2 a stagné parce que chaque nouvelle soumission ne modifiait qu'une partie d'une app qui restait surtout un site web.

Comment éviter que le même rejet se reproduise ?

Transformez chaque problème résolu en élément de votre checklist de release et retestez-le dans le build de release avant chaque soumission. Les règles d'Apple préviennent que l'examen « prendra plus de temps » si une app est rejetée à plusieurs reprises pour la même violation.

• Supprimez l'app, puis installez le build de release depuis zéro sur un iPhone et un iPad physiques.
• Connectez-vous avec le compte d'examen sur un réseau sans serveurs de développement ni exceptions HTTP.
• Ouvrez chaque demande d'autorisation et vérifiez que chaque description d'usage existe dans Info.plist.
• Vérifiez que chaque achat intégré est soumis, visible et expliqué dans les notes pour l'examen.
• Mettez à jour les notes pour l'examen dès qu'un parcours change. Ne recollez pas des notes vieilles de six releases.

Pour les problèmes 2.1, suivez le plan de test du build de release pour les rejets 2.1 et configurez un compte de démo pour l'examinateur. Passez ensuite en revue la checklist de soumission pour le prochain build. Si le message d'examen vous laisse encore bloqué, envoyez-nous les détails : nous vous aiderons à déterminer si ce qui manque relève de l'accès, des métadonnées ou du code.