Ce que la review App Store coûte vraiment aux équipes

Affichage des 111 histoires.

1. 

   4.3(a) Spam iOS Directive 4.3

   Tout un portefeuille d'apps signalé d'un coup

   Ce qui s'est passé

   Un développeur qui avait plusieurs apps créées à partir du même projet de départ a reçu la même notification 4.3 pour chacune : les apps partageaient un binaire, des métadonnées ou un concept similaires, avec seulement des différences mineures. Il a décidé de traiter les apps une par une.

   Résolution

   Toujours en cours au moment de la publication.

   Leçon

   La règle 4.3(a) couvre également le chevauchement entre vos propres applications. Si plusieurs apps sont issues d'un même template, chacune doit avoir un cœur réellement distinct, pas seulement une nouvelle icône et un nouveau nom.

2. 

   4.3(a) Spam iOS Directive 4.3

   La même lettre deux fois en une semaine

   Ce qui s'est passé

   Une petite appli d'assistance photo à fonction unique a été rejetée au titre de la règle 4.3(a) en pleine nuit, une semaine après avoir reçu exactement le même texte de rejet pour un build précédent.

   Résolution

   Non précisée.

   Leçon

   Resoumettre avec des changements cosmétiques fait rarement changer une décision 4.3. Changez le concept ou expliquez clairement dans les notes de review ce qui différencie l'app.

3. 

   4.3 Design / Spam iOS Directive 4.3

   Développer dans une catégorie saturée

   Ce qui s'est passé

   Un développeur solo qui documentait un défi de build quotidien a reçu un rejet 4.3 Design / Spam au quatrième jour et a commencé à se demander si le choix d'une catégorie saturée n'avait pas été une erreur.

   Résolution

   Non précisée.

   Leçon

   Les catégories qu'Apple liste comme saturées font l'objet d'un examen plus strict. Validez ce qui différencie votre app avant de compiler, pas après la revue.

5. 

   2.1 Informations requises iOS Directive 2.1

   Sept questions pour un nouveau compte

   Ce qui s'est passé

   La toute première soumission d'une équipe a été refusée au titre de la règle 2.1 Informations requises : sept questions, une demande d'enregistrement d'écran et un compte de démo. Répondre honnêtement a fait apparaître quatre points qu'ils avaient manqués.

   Résolution

   Ils ont corrigé les problèmes et répondu.

   Leçon

   Les nouveaux comptes développeurs doivent s'y attendre. Préparez un compte de démo, un enregistrement et des notes de révision claires avant de soumettre.

6. 

   2.1 Exhaustivité de l'app iOS Directive 2.1

   Le relecteur n'a pas pu comprendre l'app

   Ce qui s'est passé

   Un développeur novice a essuyé deux refus avant de pouvoir publier. Le premier rejet, lié à la règle 2.1, est survenu car le relecteur n'arrivait pas à comprendre comment utiliser l'app.

   Résolution

   Approuvée après l'ajout d'une vidéo de démo enregistrée sur un appareil réel et de notes de relecture étape par étape.

   Leçon

   Les relecteurs n'ont que quelques minutes et aucun contexte. Dites-leur exactement sur quoi appuyer et ce qu'ils doivent voir.

7. 

   Configuration des métadonnées et des achats in-app iOS Métadonnées et IAP

   Deux refus pour des cases à cocher connues

   Ce qui s'est passé

   Un développeur indie s'est fait refuser deux fois pour des choses qu'il connaissait déjà. D'abord, le build a été soumis sans ses achats in-app associés et la description ne renvoyait pas vers les conditions d'utilisation. Quelques semaines plus tard, une capture d'écran indiquait que l'app était gratuite.

   Résolution

   Corrigé et soumis à nouveau à chaque fois.

   Leçon

   Utilisez une checklist de pré-soumission pour les métadonnées, les abonnements et les liens légaux. La plupart des refus de métadonnées sont évitables.

8. 

   Temps d'attente de la file de revue iOS Révision sans fin

   9 jours d'attente, puis 8 jours en révision

   Ce qui s'est passé

   Un développeur a attendu neuf jours que le statut passe de « En attente de révision » à « En cours de révision », puis est resté en révision huit jours de plus sans aucune nouvelle.

   Résolution

   Aucun au moment de la publication.

   Leçon

   Les délais de révision ne sont pas garantis. Ne liez jamais une date de lancement, une campagne presse ou de créateurs à une date d'approbation prévue.

9. 

   Temps d'attente de la file de revue iOS Révision sans fin

   20 jours dans la boucle rejet, fix, attente

   Ce qui s'est passé

   Pendant plus de 20 jours, un développeur a enchaîné rejet, fix, attente de review, rejet, fix, et attendait toujours au moment de son post.

   Résolution

   En attente.

   Leçon

   Chaque aller-retour peut coûter des jours. Regroupez tous les fix d'un message de rejet dans un seul build.

10. 

    Résiliation de compte iOS Résiliation de compte

    Clôturé avant le premier examen

    Ce qui s'est passé

    Un développeur avec dix ans d'expérience s'est vu fermer son compte développeur, avec une accusation de fraude qui ne précisait pas ce qu'il avait fait, alors qu'un jeu d'apprentissage des langues attendait encore son tout premier examen. Ses applications existantes ont disparu et ses clients ont commencé à demander pourquoi.

    Résolution

    Aucun signalement.

    Leçon

    La clôture d'un compte supprime toutes les applications d'un coup. Gardez votre propre canal avec vos utilisateurs (e-mail, site web) pour pouvoir les joindre si le store disparaît.

11. 

    Avertissement de résiliation de compte iOS Résiliation de compte

    Trop de versions rejetées

    Ce qui s'est passé

    Un développeur indépendant prolifique a reçu un avis indiquant que son compte serait résilié dans dix jours. Apple a indiqué que le nombre de versions rejetées faisait partie des raisons. Après la médiatisation de l'affaire et un appel, le compte n'a pas été résilié.

    Résolution

    Compte maintenu après appel.

    Leçon

    Les rejets s'accumulent. Évitez les resoumissions le jour même avec un seul mot modifié et les clones quasi identiques de vos propres apps.

12. 

    Exigence de connexion (numéro de directive non précisé) iOS Connexion obligatoire

    Inscription requise : vous n'êtes pas une grosse app

    Ce qui s'est passé

    L'app sociale d'un développeur a été refusée parce qu'elle obligeait à créer un compte avant d'atteindre le fil d'accueil. Quand le développeur a expliqué que chaque utilisateur a besoin d'un pseudo pour que l'app fonctionne, et a cité un grand réseau de partage de photos qui fait pareil, le reviewer a répondu, en substance, que son app n'était pas ce réseau-là.

    Résolution

    Non précisée.

    Leçon

    Ce que les grandes apps se permettent ne constitue pas un précédent que vous pouvez invoquer. Si vous imposez une inscription, expliquez dans les notes de review pourquoi la fonctionnalité principale ne peut pas fonctionner sans compte, et envisagez de laisser les reviewers ou les invités voir du contenu d'abord.

13. 

    4.3 Spam iOS Directive 4.3

    De l'absence de revue au rejet massif

    Ce qui s'est passé

    Un développeur a constaté qu'aucune de ses apps n'était examinée pendant plusieurs jours. En attendant, il a multiplié les soumissions sur environ une semaine. Quand la revue a enfin bougé, presque toutes ont été rejetées au titre de la règle 4.3 sur le spam.

    Résolution

    Non précisée.

    Leçon

    Une file d'attente bloquée n'est pas un signal pour soumettre davantage. Empiler les soumissions alors que rien n'est examiné peut faire passer votre compte pour un schéma de spam quand un reviewer les voit enfin toutes ensemble.

14. 

    4.3 Spam iOS Directive 4.3

    Des applications sans lien rejetées ensemble

    Ce qui s'est passé

    Un développeur avait plusieurs applications, développées sur plusieurs mois et sans rapport les unes avec les autres, toutes rejetées pour spam au même moment. Il a demandé publiquement si c’était normal.

    Résolution

    Non précisée.

    Leçon

    La règle 4.3 peut s’appliquer au niveau du compte, et non application par application. Si plusieurs applications sont rejetées d’un coup, répondez à chacune séparément et précisez dans les notes de revue ce qui distingue chaque application.

15. 

    Temps d'attente de la file de revue iOS Révision sans fin

    Un refus, puis deux mois de silence

    Ce qui s'est passé

    Après un seul refus, l’application d’un développeur est restée en review pendant environ deux mois, avec des cycles de review d’environ un mois. Il soupçonnait ces cycles interminables d’être devenus un moyen de tenir les nouvelles applications à l’écart.

    Résolution

    Toujours bloqué au moment d’écrire ces lignes.

    Leçon

    Après un refus, le cycle suivant peut être bien plus lent que le premier. Soignez votre nouvelle soumission : complète et bien documentée, elle vous évitera un mois de plus d’aller-retour.

16. 

    Contenu répréhensible iOS Contenu répréhensible

    Rejetée pour resoumission sans correction

    Ce qui s'est passé

    Une application de retouche photo par IA a été rejetée car elle avait été resoumise plusieurs fois sans corriger le problème signalé par Apple : du contenu répréhensible.

    Résolution

    Rejetée.

    Leçon

    Resoumettre le même build en espérant tomber sur un autre évaluateur peut se retourner contre vous. Corrigez le problème signalé ou demandez des précisions via le Resolution Center avant de resoumettre. Pour les fonctionnalités d'IA générative, ajoutez des filtres pour le contenu qu'Apple juge répréhensible.

17. 

    4.3 Spam iOS Directive 4.3

    Rejeté dès le début de la revue

    Ce qui s'est passé

    Un développeur a passé des semaines à développer une app, et elle a été rejetée pour spam (4.3) à la minute même où elle est passée en revue. Il pensait que le reviewer avait jugé la niche, pas l'app.

    Résolution

    Non précisée.

    Leçon

    Dans les niches saturées, un rejet 4.3 peut tomber avant même que quiconque regarde de près. Mettez en tête de vos notes de revue ce qui est unique et orientez directement le reviewer vers ce point.

18. 

    4.2.6 Modèle iOS Règle 4.2.6

    Signalé pour un template jamais utilisé

    Ce qui s'est passé

    Une équipe a été rejetée au titre de la règle 4.2.6, qui couvre les apps créées à partir d'un template commercialisé ou d'un service de génération d'apps, alors qu'elle n'a utilisé ni template ni service de génération.

    Résolution

    Non précisée.

    Leçon

    La règle 4.2.6 peut être un faux positif. Répondez dans le Resolution Center en indiquant simplement que l'app est développée sur mesure et qui l'a développée, et proposez de montrer le code source ou l'historique de développement.

19. 

    3.1.2 Abonnements iOS Règle 3.1.2

    Le prix mensuel était supérieur au prix facturé

    Ce qui s'est passé

    Le paywall d’un développeur a été refusé parce qu’il affichait le prix mensuel calculé d’un abonnement plus long de façon plus visible que le montant réellement facturé. Ce même paywall avait passé les précédentes revues sans commentaire. Ils étaient d’accord avec la règle, mais frustrés que ce ne soit signalé qu’aujourd’hui, et ont redessiné le paywall pour mettre en avant le montant facturé.

    Résolution

    Soumis à nouveau avec le nouveau design.

    Leçon

    Un paywall validé par le passé peut encore être refusé plus tard. Mettez toujours le montant facturé et la période au premier plan ; affichez le détail par mois plus petit et en second plan.

20. 

    Inscription (pas une règle de l'App Review) Programme Apple Developer Inscription et compte

    Deux mois, puis un refus sans raison

    Ce qui s'est passé

    Un développeur a passé plus de deux mois à tenter de s'inscrire, multipliant les appels au support, les e-mails, la vérification d'identité, les détails de l'appareil et même des preuves vidéo. Apple a ensuite rejeté l'inscription sans donner de raison précise.

    Résolution

    Aucun au moment de la publication.

    Leçon

    L'inscription peut prendre bien plus de temps que le build de l'app. Commencez l'inscription tôt, avant que votre plan de lancement n'en dépende, et gardez une trace de chaque échange avec le support.

21. 

    5.1.2 Utilisation et partage des données iOS Règle 5.1.2

    Un rejet lié à App Tracking Transparency qui a menacé une startup

    Ce qui s'est passé

    Après quelques mois de déploiements rapides et de bons retours utilisateurs, l'application d'une startup a été rejetée à la fin de l'automne à cause d'App Tracking Transparency, la règle de confidentialité d'iOS qui exige l'autorisation de l'utilisateur avant tout suivi entre applications et sites web. Le fondateur a décrit plus tard ce rejet comme ayant mis toute l'entreprise en péril.

    Résolution

    Non précisé dans le post.

    Leçon

    Auditez chaque SDK de votre application pour détecter tout suivi avant de soumettre. Si un élément relie les données utilisateur aux données d'autres entreprises, vous devez afficher le prompt d'autorisation de suivi et les étiquettes de confidentialité correspondantes, même si le suivi provient d'une bibliothèque tierce.

22. 

    Connexion (numéro de directive non précisé) iOS Connexion

    Le relecteur n'a pas pu se connecter avec Apple ou Google

    Ce qui s'est passé

    Pour empêcher les inscriptions de bots, un développeur a supprimé la connexion par e-mail et mot de passe pour ne garder que Sign in with Apple et Google. Cela fonctionnait sur son propre iPhone et iPad, et même pour le relecteur précédent, qui avait refusé l'app pour une autre raison. Le relecteur suivant l'a refusée car il ne pouvait pas se connecter.

    Résolution

    Non précisée.

    Leçon

    Si votre app ne propose que le social login, les relecteurs peuvent quand même être bloqués. Donnez-leur un accès fonctionnel dans les notes de révision, comme un compte de démo ou un login réservé à la révision, et testez la connexion sur un appareil et un compte neufs avant chaque soumission.

23. 

    Jeux d'argent simulés (numéro de directive non précisé) iOS Jeux d'argent simulés

    Une fonctionnalité de staking dans le jeu sur un compte individuel

    Ce qui s'est passé

    Un jeu a été rejeté pour avoir inclus des jeux d'argent simulés : les joueurs pouvaient miser des objets du jeu les uns contre les autres, une mécanique courante dans les jeux de rôl’en ligne classiques. Comme le développeur publiait sous un compte individuel plutôt qu'un compte entreprise, il a décidé de retirer la fonctionnalité pour le moment.

    Résolution

    Suppression de la fonctionnalité et nouvelle soumission.

    Leçon

    Les mécaniques de type jeux d'argent font l'objet d'un examen plus poussé même sans argent réel, et une partie de ce qu'Apple autorise dépend de votre type de compte et de votre documentation. Vérifiez les règles sur les jeux d'argent avant de développer des fonctionnalités de staking, de loot ou de pari, et choisissez votre type de compte développeur en conséquence.

24. 

    Faux documents (numéro de règle non précisé) iOS Faux documents

    Un éditeur PDF mis en cause pour les actes de ses utilisateurs

    Ce qui s'est passé

    Une application d'édition PDF a été rejetée car Apple estimait qu'elle permettait de créer de fausses pièces d'identité et de faux documents. Le développeur a fait valoir que, selon la même logique, n'importe quelle application bancaire ou de messagerie pourrait être rejetée pour ce que des acteurs malveillants pourraient en faire.

    Résolution

    Non précisée.

    Leçon

    Les outils polyvalents peuvent être jugés sur leur pire usage possible. Évitez les templates ou le marketing qui ressemblent à des pièces d'identité ou des certificats officiels, et expliquez dans les notes de review à quoi sert l'app et ce qu'elle ne prend pas en charge.

25. 

    Partage de données avec l'IA (numéro de règle non précisé) iOS Partage de données avec l'IA

    Pas d'écran de consentement pour partager des données avec une IA tierce

    Ce qui s'est passé

    Une équipe a reçu son premier rejet pour avoir partagé des données utilisateur avec un fournisseur d'IA tiers. Apple exigeait une autorisation explicite des utilisateurs et une indication claire des données envoyées et du fournisseur d'IA concerné. L'inquiétude de l'équipe : concevoir un écran de consentement qui passe la review sans nuire à la conversion.

    Résolution

    En cours.

    Leçon

    Si votre app envoie du contenu utilisateur à un service d'IA externe, recueillez le consentement avant la première requête et précisez le fournisseur et les données concernées. Prévoyez cet écran avant la soumission, pas après le rejet.

26. 

    Entitlement Family Controls (numéro de guideline non précisé) iOS Métadonnées et IAP

    Cinq refus pour une case non cochée

    Ce qui s'est passé

    Un développeur qui publiait une app de type Screen Time a été refusé cinq fois. Des commentaires de review vagues lui ont fait croire que le design était en cause. La vraie cause : un seul réglage Family Controls non coché dans sa configuration développeur. Une fois la case cochée, l'app est passée.

    Résolution

    Approuvé après activation du réglage Family Controls et nouvelle soumission.

    Leçon

    Quand les motifs de refus restent vagues, vérifiez vos entitlements et certificats avant de refondre le produit. Les apps de type Screen Time et Family Controls ont besoin de la capability correspondante activée dans le portail développeur, pas seulement dans Xcode.

27. 

    Directive 5.1.1(v) iOS Règle 5.1.1 Connexion obligatoire

    Compte requis pour une fonctionnalité payante qui s'exécute sur l'appareil

    Ce qui s'est passé

    Un développeur venu du web a été refusé au titre de la directive 5.1.1(v). Sur le web, les achats étaient toujours liés à un compte. Sur iOS, c'est Apple qui gère l'achat : les acheteurs peuvent donc payer sans s'inscrire. Son offre payante débloquait des filtres sur l'appareil qui ne tournaient que sur le téléphone, mais le déblocage de cette offre et la restauration des achats forçaient quand même à créer un compte au préalable.

    Résolution

    Refonte en cours pour qu'un achat effectué sans compte soit rattaché à son propriétaire après une inscription facultative. En cours au moment de la publication.

    Leçon

    Si une fonctionnalité payante s'exécute sur l'appareil et n'a pas besoin d'une identité serveur, laissez les utilisateurs l'acheter et la restaurer sans compte. Réservez l'inscription aux fonctionnalités qui en ont réellement besoin, comme la sauvegarde cloud.

28. 

    Directive 1.4.2 Dommages physiques iOS Règle 1.4.2

    Les apps de calcul de dosage retirées suite à un durcissement des règles

    Ce qui s'est passé

    Un développeur s'est réveillé pour découvrir que deux de ses apps étaient signalées sous la directive 1.4.2, alors qu'aucune n'était en cours de révision. Les deux étaient déjà en ligne : un calculateur de dosage de peptides autonome et un tracker intégrant ce même calculateur, qui constituaient ensemble leur premier véritable succès commercial. D'autres développeurs dans la même niche ont reçu la même notification au même moment. Elle stipulait que les apps calculant des doses de médicaments, y compris le dosage et la reconstitution de peptides, doivent être publiées par le fabricant du médicament ou une institution reconnue telle qu'un hôpital, un assureur, une pharmacie ou une université.

    Résolution

    Aucun. Le développeur a déclaré avoir compris les enjeux de sécurité et a considéré cela comme la fin de ces apps.

    Leçon

    L'approbation n'est pas permanente. Apple peut réévaluer une app en ligne lorsqu'elle durcit une règle. Si votre app calcule des doses ou donne des conseils de santé pouvant nuire à quelqu'un, lisez la directive 1.4 avant de compiler, et prévoyez de publier via une institution qualifiée ou de retirer le calcul.

29. 

    Règles 4.3 (Spam) et 4.2.6 (Services de génération d’applications) iOS Directive 4.3 Règle 4.2.6

    Encore du spam : une app de billetterie hors ligne

    Ce qui s'est passé

    Un développeur a créé une petite application qui transforme un tableur en système de billetterie et de check-in fonctionnant entièrement hors ligne, sans compte ni abonnement. Elle avait déjà géré l’entrée d’un événement local avec plusieurs centaines de participants cet été. Apple l’a rejetée à nouveau avec un avis combinant les points 4.3 et 4.2.6, affirmant qu’elle pourrait dupliquer des applications déjà présentes sur le store, qu’il s’agirait d’une variante opportuniste d’une catégorie saturée, ou qu’elle proviendrait d’un modèl’ou d’un service de génération d’applications. Le développeur a indiqué ne connaître aucune autre application faisant la même chose, et que la version Android était en ligne depuis environ une semaine.

    Résolution

    Toujours rejetée au moment de la publication. Le développeur a précisé qu’il ne cherchait de toute façon pas à gagner d’argent avec l’App Store.

    Leçon

    Un examinateur 4.3 voit votre fiche et quelques minutes de l’application, pas vos utilisateurs réels. Si l’application est réellement différente, expliquez précisément en quoi dans les notes d’examen et les premières captures d’écran, mentionnez l’usage en conditions réelles, et indiquez clairement que vous n’avez utilisé ni modèle ni générateur d’applications.

30. 

    Règle 5.6.4 App Quality Programme Apple Developer Règle 5.6.4

    Paiements gelés à cause d'un taux de remboursement en hausse

    Ce qui s'est passé

    Un développeur gérant une application par abonnement en pleine croissance s'est réveillé avec un avertissement d'Apple indiquant que son compte enfreignait le Code de conduite des développeurs selon la règle 5.6.4, App Quality. L'avis signalait un nombre excessif de demandes de remboursement et de plaintes clients, avertissait que le compte pourrait être résilié, et précisait que tous les paiements de revenus étaient suspendus et les transferts d'applications désactivés. Le taux de remboursement avait quasiment doublé au cours des deux derniers mois. En analysant les données, le développeur a constaté que la plupart des demandes de remboursement étaient étiquetées comme des achats involontaires, provenant principalement d'utilisateurs ayant oublié d'annuler un essai gratuit de 3 jours qui se transformait en abonnement annuel. L'avertissement est tombé alors qu'une importante refonte de l'application était déjà en phase de test.

    Résolution

    Le dossier est toujours ouvert au moment de la publication. Le développeur a ajouté davantage de rappels pendant l'essai, a rendu le prochain prélèvement plus explicite, a intégré un moyen de gérer et d'annuler l'abonnement directement dans l'app, a terminé la refonte avec plus de tests, et a suspendu tout le marketing payant des créateurs en attendant.

    Leçon

    Apple examine les taux de remboursement et les plaintes, pas seulement votre binaire. Un essai gratuit qui se transforme discrètement en facturation annuelle peut devenir un problème d'achats involontaires à grande échelle. Rappelez la fin de l'essai aux utilisateurs, affichez clairement le prix réel, facilitez la résiliation et traitez une hausse du taux de remboursement comme un risque pour votre compte bien avant qu'Apple ne le fasse.

31. 

    Configuration des métadonnées et des achats in-app iOS Métadonnées et IAP

    Rejeté trois fois à cause d'une image que la console refusait de supprimer

    Ce qui s'est passé

    Un développeur a ajouté une image promotionnelle à un abonnement dans App Store Connect et s'est retrouvé par erreur avec la même image ajoutée deux fois. Ensuite, impossible de supprimer ou de remplacer l'image : chaque tentative échouait avec une erreur générique demandant de réessayer plus tard. L'application a été rejetée trois fois à cause de cette configuration d'abonnement. À chaque fois, le développeur répondait en joignant un enregistrement d'écran de la tentative de suppression et de l'erreur, et à chaque fois le reviewer semblait l'ignorer. Le développeur pensait que la cause racine était un bug dans App Store Connect lui-même.

    Résolution

    Toujours bloqué au moment de la publication du post, sans correctif de la part d'Apple.

    Leçon

    Lorsque App Store Connect bloque lui-même la correction, une réponse dans le fil de rejet peut ne pas atteindre la bonne personne. Uploadez les images d’abonnement avec soin et une seule fois. Si la console plante, contactez le support développeur Apple séparément pour signaler le bug, tout en répondant à App Review.

32. 

    Ligne directrice 4.3 Spam iOS Directive 4.3

    Trois rejets pour une app conçue pour un seul gymnase

    Ce qui s'est passé

    Un développeur a créé une application iOS pour gérer sa propre salle de sport, soit environ 176 commits de travail. Apple l’a rejetée le 29 septembre, puis à nouveau le 7 octobre, et le 13 octobre sous la ligne directrice 4.3 Spam. Le même jour, il a répondu aux neuf questions envoyées par App Review. Six jours plus tard, le 19 octobre, il n’avait toujours rien reçu. La liste des applications de son compte App Store Connect montrait que plusieurs autres apps du même compte étaient également dans un état de rejet simultanément, sur iOS et macOS.

    Résolution

    Toujours ouvert au moment de la publication, sans réponse d’App Review après l’envoi des réponses.

    Leçon

    L'effort et le nombre de commits ne sont pas ce que mesure la règle 4.3. Si une app est vraiment conçue pour une seule entreprise, une app non répertoriée peut rester hors des résultats de recherche tout en restant accessible à toute personne disposant de son lien direct ; la distribution Custom App limite la disponibilité à des organisations spécifiques. Choisissez l'option qui correspond au contrôle d'accès requis. Pour une publication publique, rendez évident dès les premiers écrans, les captures d'écran et les notes de review ce qui différencie votre app des apps existantes.

33. 

    Règles 5.6 Developer Code of Conduct et 2.5.19 Hidden Features iOS Règle 5.6 Code de conduite du développeur Règle 2.5.19 Fonctionnalités cachées

    Rejetée pour fraude à cause de switchs de test oubliés

    Ce qui s'est passé

    En septembre 2026, un développeur a vu son app iOS refusée au titre de la directive 5.6 du Code de conduite des développeurs. Apple a déclaré avoir identifié un schéma de comportement qu'elle associe à la fraude, notamment des fonctionnalités qui semblaient avoir été délibérément cachées pendant la revue. Le développeur a remonté la piste jusqu'à trois switchs de test laissés dans le build de release : un mode pour prendre les captures d'écran pour le store, un switch qui simulait un contrôle d'entitlement lent, et un switch qui débloquait des achats fictifs. Aucun n'était accessible aux utilisateurs normaux de la version App Store. Dans la mise à jour des directives d'App Review d'Apple du 16 octobre, les fonctionnalités cachées, dormantes ou non documentées sont devenues une directive à part entière, la 2.5.19, et Apple précise qu'enfreindre cette directive peut mettre en péril tout le compte développeur.

    Résolution

    Le développeur inspecte désormais les strings de chaque archive de release avant l'upload. Il n'a pas été précisé si ce build spécifique a finalement été approuvé.

    Leçon

    Excluez les code de test des builds de release au moment de la compilation, par exemple avec des flags DEBUG, plutôt que via une vérification au runtime. Vérifiez ce qui est réellement embarqué dans le binaire archivé, et listez dans les notes d'App Review tout switch qui reste.

34. 

    2.1 Informations requises iOS Directive 2.1

    Revue en pause jusqu'à ce qu'Apple sache à qui l'app était destinée

    Ce qui s'est passé

    Un développeur a soumis la version 1.0 d'une application iPad et la review s'est arrêtée sur la règle 2.1, Information Needed. Aucun rapport de crash, aucune fonctionnalité cassée, aucune correction du binaire demandée. Apple voulait juste une réponse détaillée à une question avant de poursuivre la review : qui allait utiliser cette application ?

    Résolution

    Apple a demandé une explication sur l'utilisateur cible avant de poursuivre l'examen.

    Leçon

    Considérez l'audience et les cas d'usage comme des éléments de la review, pas comme du texte marketing que vous compléterez plus tard. Rédigez une réponse claire sur l'utilisateur cible avant de soumettre une première version.

35. 

    4.3 Conception / Spam iOS Directive 4.3

    Pas assez distinctif dans une catégorie d'applications audio saturée

    Ce qui s'est passé

    Une application de sons de divertissement a été rejetée au titre de la règle 4.3(b). Apple a estimé que le store comptait déjà suffisamment d'applications similaires et a considéré le produit comme du contenu dupliqué dans une catégorie saturée, alors même que l'équipe estimait que des fonctionnalités supplémentaires le distinguaient.

    Résolution

    Refusé selon la règle 4.3(b) pour manque de différenciation dans une catégorie saturée.

    Leçon

    Dans les catégories qu'Apple qualifie de saturées, la nouveauté doit sauter aux yeux dès la première minute de review. Mettez en avant ce qui est unique, pas un gadget que les reviewers ont déjà vu des dizaines de fois.

36. 

    Métadonnées et texte de la fiche produit iOS Métadonnées et IAP Révision sans fin

    La boucle de métadonnées qui a plombé le lancement

    Ce qui s'est passé

    Une équipe de productivité grand public a livré un build propre, puis a passé plus de neuf jours à enchaîner les objections sur les métadonnées. Chaque nouvelle soumission répondait à la remarque précédente, mais la réponse suivante portait sur une autre phrase, capture d'écran ou explication. Aucun code n'a changé pendant que les plans de lancement, de presse et d'acquisition payante attendaient la validation du texte.

    Résolution

    Approuvé après réécriture des captures d’écran, sous-titres et notes de revue, sans modification du binaire.

    Leçon

    Verrouillez le texte de la fiche, les captures d'écran et les notes de review en une seule passe avant de fixer une date de lancement. Les rejets de métadonnées peuvent s'accumuler même si le binaire ne bouge jamais.

37. 

    Conformité à l'exportation (App Store Connect) iOS Métadonnées et IAP

    Approuvé, puis bloqué par une question de conformité de plus

    Ce qui s'est passé

    Le build compagnon d'un dashboard B2B a été approuvé, mais la release est restée bloquée quand un prompt de conformité est réapparu, alors que l'équipe pensait avoir déjà répondu aux questions d'export. Le responsable de la release a stoppé le déploiement progressif, rassemblé les formulations juridiques, mis à jour la réponse dans App Store Connect et attendu un nouveau passage en revue, pendant que les clients voyaient l'annonce avant même que l'app soit disponible.

    Résolution

    Publié après avoir répondu de nouveau à la conformité à l'export et attendu le prochain passage en revue.

    Leçon

    Considérez la conformité à l'export comme un prérequis de release, pas comme une case à cocher ponctuelle. Vérifiez qu'App Store Connect affiche un état prêt pour la release avant d'annoncer une date de publication.

38. 

    Permissions Google Play et examen des politiques Google Play Métadonnées et IAP Révision sans fin

    Le piège chronophage des politiques de permissions

    Ce qui s'est passé

    Une application Android d'opérations terrain a déclenché un examen de politique approfondi après l'usage d'une permission très ciblée sur un seul écran. L'équipe a documenté la fonctionnalité, ajouté des instructions pour les réviseurs et enregistré un parcours de démo, mais a quand même dû retirer la permission de la release principale pour débloquer les clients au bout de treize jours.

    Résolution

    Approuvé après avoir supprimé la permission, enregistré une nouvelle démo et réécrit la déclaration sur le store.

    Leçon

    Limitez les permissions sensibles à la surface minimale possible dès le premier déploiement. Une seule permission peut déclencher un examen complet de conformité sur Google Play.

39. 

    Temps d'attente de la file de revue Google Play Google Play Révision sans fin

    Le hotfix bloqué dans la file de validation

    Ce qui s'est passé

    Une équipe e-commerce avait besoin d'un correctif mobile rapide pour un bug de checkout, mais la release sur le store est restée en validation pendant six jours, au pire moment possible. Les tickets support s'accumulaient alors que le statut restait en attente. Ils ont d'abord atténué le problème côté serveur, puis ont vu la validation du binaire arriver alors que l'urgence avait déjà gâché un week-end.

    Résolution

    Le correctif natif du store est arrivé après que l'équipe avait déjà atténué l'incident par ailleurs.

    Leçon

    La revue des stores n'est pas un canal de réponse aux incidents. Prévoyez une voie d'atténuation hors store pour les bugs de production urgents pendant qu'un binaire attend en file d'attente.

40. 

    Directives 3.1.1 Achats intégrés et 3.1.3(f) Applications autonomes gratuites iOS Directive 3.1.1 Directive 3.1.3

    Une application compagnon rejetée car son essai se termine

    Ce qui s'est passé

    Un développeur a publié une application compagnon iOS gratuite pour son service d'e-mail payant basé sur le web. L'application n'y vendait rien. Il a invoqué auprès de l'App Review l'exception 3.1.3(f) pour les applications compagnon autonomes gratuites, mais l'application a été rejetée quatre fois. Il a fait appel, et l'App Review Board a confirmé le rejet. Le motif était que le service proposait un essai gratuit de 14 jours : pour un utilisateur iOS, l'application perdait donc son utilité au bout de 14 jours et n'était pas une véritable expérience autonome. Apple a proposé deux issues : donner à l'application assez de contenu et de fonctionnalités gratuits pour qu'elle soit indépendante, ou permettre aux clients de l'App Store d'acheter le service via l'achat intégré. Le développeur a souligné qu'une application d'e-mail très connue semblait faire la même chose avec une limite de 14 jours.

    Résolution

    Toujours pas résolu au moment de la publication. Le recours a échoué, et le développeur hésitait entre un niveau gratuit minimal et l'ajout d'achats intégrés.

    Leçon

    L'exception pour les apps compagnes 3.1.3(f) est interprétée de façon restrictive. Si votre service web propose un essai limité dans le temps, Apple peut considérer l'app comme un paywall déguisé une fois l'essai terminé. Avant l'envoi, déterminez ce qu'un utilisateur peut encore faire gratuitement dans l'app après l'essai, ou prévoyez des achats intégrés. Citer d'autres apps qui semblent faire la même chose permet rarement de faire aboutir un recours.

41. 

    Règle 3.1.1 : achats intégrés iOS Directive 3.1.1

    Apportez votre propre clé API considérée comme un paiement hors de l'App Store

    Ce qui s'est passé

    Un développeur solo qui créait un assistant IA pour iPhone laissait les utilisateurs coller leur propre clé API provenant d'un agrégateur de modèles tiers afin de faire tourner de grands modèles cloud. Lors du quatrième passage en revue, l'App Review a rejeté l'application au titre de la règle 3.1.1, en considérant l'option « apportez votre propre clé » comme un moyen de payer des fonctionnalités hors de l'App Store. D'après ce que le développeur a compris du rejet, une clé achetée ailleurs ne peut débloquer des fonctionnalités payantes dans l'app que si ce vendeur propose l'In-App Purchase dans sa propre application iOS, or ce fournisseur n'a pas d'application iOS. Le développeur n'a pas fait appel.

    Résolution

    Il a entièrement supprimé la fonctionnalité « apportez votre propre clé », a reconstruit la version suivante pour faire tourner les modèles entièrement sur l'appareil, et prévoyait de réintroduire les modèles cloud plus tard sous forme de crédits in-app vendus via l'In-App Purchase. Le résultat de cette nouvelle soumission n'était pas connu au moment de la rédaction.

    Leçon

    Si une fonctionnalité payante de votre app est débloquée par des identifiants achetés ailleurs, vérifiez avant de compiler si ce vendeur propose l'In-App Purchase dans sa propre app iOS. Sinon, prévoyez votre propre parcours d'In-App Purchase ou un mode qui fonctionne sans.

42. 

    Directive 1.2 iOS Directive 1.2

    Une comparaison de tenues rejetée pour avoir désigné un vainqueur

    Ce qui s'est passé

    Un développeur solo a déployé une app IA qui compare deux tenues. Après la comparaison, l'app annonçait qu'un look avait gagné. L'App Review l'a rejetée au titre de la directive 1.2, interprétant le résultat comme un classement de personnes plutôt que de vêtements. Le développeur partageait cette inquiétude.

    Résolution

    Il a supprimé toute mention de vainqueur, le badge de victoire, ainsi que tout score plus élevé ou couleur de mise en avant sur l'une ou l'autre option. Désormais, les deux looks ont le même poids visuel, chacun reçoit son propre feedback, et c'est l'utilisateur qui décide. On ne sait pas si le build corrigé a été approuvé.

    Leçon

    Apple juge le ressenti d'un écran, pas seulement ce qu'il fait. Si votre app attribue un score lié à l'apparence des personnes, présentez le feedback sans classement et partez du principe que l'interprétation sera la plus sévère.

43. 

    Catégorie Kids, directive 3.1.2 et questions de confidentialité iOS Catégorie Enfants Règle 3.1.2 Révision sans fin

    Une appli de contes pour enfants toujours en attente après un mois de refus

    Ce qui s'est passé

    Un développeur solo a créé une application de contes pour les enfants de 4 à 10 ans, où ils écoutent des histoires et peuvent faire une pause pour poser des questions. L'app était déjà disponible sur Android depuis des semaines. Il l'a soumise à l'App Store le 19 septembre 2026. Après plusieurs refus et nouvelles soumissions, elle n'était toujours pas approuvée près d'un mois plus tard. Dans le dernier retour, Apple a demandé deux choses : comme l'app propose des abonnements hebdomadaires, mensuels et annuels, la page de l'App Store devait contenir un lien fonctionnel vers les Conditions d'utilisation ; et comme l'app est dans la catégorie Enfants, la review ne pouvait pas se poursuivre tant que le développeur n'avait pas répondu à quatre questions : les analytics tiers, les publicités tierces, le partage éventuel de données avec des tiers et leur lieu de stockage, et la collecte éventuelle d'autres données utilisateur ou appareil et dans quel but.

    Résolution

    Le développeur a corrigé les deux problèmes et a resoumis l'app. Résultat toujours en attente au moment de la publication.

    Leçon

    Pour les apps destinées aux enfants, à la santé, à la finance ou à l'éducation, renseignez-vous tôt sur ce que la loi locale sur la vie privée et les stores vont exiger : par exemple le consentement parental avant de collecter les données d'un enfant. Préparez aussi le lien vers les Conditions d'utilisation et une réponse écrite sur les données avant la première soumission.

44. 

    Directives 5.1.1(v) et 3.1.2 iOS Règle 5.1.1 Règle 3.1.2

    Version 1.0 refusée pour les flux de connexion, d'achat et de suppression

    Ce qui s'est passé

    La version 1.0 d'un développeur a été refusée pour trois motifs à la fois, aucun ne concernant l'idée de l'app elle-même. Après une connexion via Sign in with Apple, l'app demandait encore à l'utilisateur un nom que Sign in with Apple avait déjà fourni. La suppression de compte devait pouvoir être lancée depuis l'app. L'écran d'abonnement et de support devait afficher le prix, les conditions de renouvellement et un lien vers les conditions d'utilisation. Le développeur en a conclu que les trois problèmes concernaient la connexion, l'achat et la suppression.

    Résolution

    Non précisée.

    Leçon

    Avant une première soumission, testez les flux de connexion, d'achat et de suppression de compte comme un réviseur. Ces trois flux sont à l'origine de nombreux premiers refus.

45. 

    Règle 5.2.3 Téléchargement d'audio et de vidéo iOS Règle 5.2.3 Téléchargement d'audio et de vidéo

    Radio internet vintage bloquée pour des droits audio tiers

    Ce qui s'est passé

    L'application de radio internet d'un développeur solo au look vintage, en version 1.0 à son cinquième build, a été rejetée au titre de la règle 5.2.3. Celle-ci concerne les apps qui diffusent ou téléchargent de l'audio et de la vidéo provenant de sources tierces et exige la preuve que le développeur détient les droits sur ce contenu. Le développeur a répondu le lendemain dans le Resolution Center avec des explications sur les droits de contenu.

    Résolution

    Résultat inconnu au moment de la publication.

    Leçon

    Si votre app diffuse des stations ou des médias qui ne vous appartiennent pas, obtenez une autorisation ou utilisez des sources dont les conditions permettent explicitement la lecture dans une app, puis joignez cette documentation aux notes de révision avant la soumission.

46. 

    Directive 4.3 (Spam) iOS Directive 4.3

    Six rejets, puis un label spam 4.3 et deux semaines d'attente pour un appel

    Ce qui s'est passé

    Un développeur solo a passé des mois sur sa première application, conçue pour briser la glace en société. Elle a été rejetée six fois, la dernière fois au titre de la directive 4.3 pour spam, alors que le développeur estimait qu'elle offrait plus que les applications similaires déjà présentes sur le store. Il a demandé un entretien individuel à l'App Review. Une semaine est passée sans réponse, et l'appel n'a finalement eu lieu que deux semaines après le rejet 4.3. Le développeur est ressorti de l'appel avec l'impression que la directive 4.3 sert désormais à signaler les apps qui ressemblent à des clones bâclés générés par IA, ce qui n'était pas le cas de son application.

    Résolution

    Le développeur a déposé un recours. Celui-ci était toujours en attente au moment de la rédaction.

    Leçon

    Dans une catégorie saturée, le reviewer juge ce que montrent les captures d'écran, la description et la première session. Rendez la différence avec les apps existantes évidente dès ce stade, et demandez tôt un appel avec l'App Review, car en obtenir un peut prendre une semaine ou plus.

47. 

    Contrat non accepté (aucune règle citée) iOS Inscription et compte

    Une semaine dans la file d'attente, rejetée pour un contrat non signé, puis encore une semaine

    Ce qui s'est passé

    Une application a attendu environ une semaine pour la revue, puis a été rejetée alors que rien dans l'app n'était en cause. Le compte n'avait pas encore accepté un contrat publié récemment dans App Store Connect. Le développeur a accepté le contrat et resoumis l'app ; la soumission est repartie dans la file d'attente pour environ une semaine de plus. Le support développeur a seulement répondu que tout était en bonne voie.

    Résolution

    Toujours en attente de revue au moment de la rédaction.

    Leçon

    Avant chaque soumission, vérifiez dans App Store Connect si des contrats attendent d'être acceptés. Un simple clic oublié peut coûter un passage complet dans la file d'attente de revue.

48. 

    Crash pendant la revue (guideline non précisée) machine macOS Directive 2.1

    Rejeté pour un crash sur une version de macOS que le développeur n'avait pas installée

    Ce qui s'est passé

    Une app Mac a été rejetée car elle crashait sur macOS 27, une version que le développeur n'utilisait pas encore et ne souhaitait pas installer sur sa machine principale. En cherchant comment reproduire le crash, il a découvert que le framework Virtualization d'Apple permet de faire tourner une machine virtuelle macOS sur Apple silicon gratuitement, et en a configuré une pour tester la nouvelle version.

    Résolution

    Non précisé, au-delà de la reproduction du crash dans une machine virtuelle.

    Leçon

    L'App Review teste sur l'OS le plus récent. Gardez une machine virtuelle avec le dernier macOS prête à l'emploi pour reproduire les crashs de la revue sans mettre à jour votre machine du quotidien.

49. 

    Retard d’examen (aucune règle citée) iOS Révision sans fin

    Douze jours en attente de révision après deux demandes de révision accélérée

    Ce qui s'est passé

    Un développeur dont les applications étaient déjà approuvées sur le store a soumis la version 1.0 d'une nouvelle app avec un groupe d'abonnements comprenant cinq abonnements. Douze jours plus tard, l'app était toujours en attente de révision, alors qu'on s'attend généralement à moins de 48 heures. Il a demandé deux fois une révision accélérée, a contacté le support sans obtenir de réponse et a tenté de réserver un rendez-vous avec l'App Review, mais la demande a été refusée.

    Résolution

    Toujours en attente au moment de la rédaction.

    Leçon

    Ne planifiez pas votre date de lancement sur la moyenne de 48 heures. Prévoyez plusieurs semaines de marge pour une première version avec abonnements, et considérez les demandes de révision accélérée et les rendez-vous App Review comme possibles, pas comme garantis.

50. 

    Prompt de permission + métadonnées des captures d'écran (règles souvent citées comme 5.1.1 et 2.3.7) iOS Règle 5.1.1 Directive 2.3.7

    Semaine de lancement : écran d'autorisation personnalisé et prix dans les captures

    Ce qui s'est passé

    Lors de la semaine de lancement, l'app a été rejetée deux fois. La première fois, elle affichait son propre écran avec un bouton Autoriser juste avant le prompt de permission système, ce qu'Apple n'accepte pas. Après correction, le second rejet venait de l'affichage de prix dans les captures d'écran de l'App Store. Les deux corrections étaient mineures, mais chaque nouvelle soumission a coûté environ une journée dans la file de révision.

    Résolution

    Le développeur a corrigé les deux problèmes et consigne désormais ces deux règles dans le projet pour éviter que cela ne se reproduise.

    Leçon

    Un écran de pré-permission peut expliquer pourquoi vous avez besoin de l'accès, mais le seul choix d'autoriser doit rester au prompt système. Évitez les prix dans les captures d'écran et passez une courte checklist avant chaque soumission.

51. 

    Retard d’examen (aucune règle citée) iOS Révision sans fin

    Dix jours bloquée en examen, puis approuvée une demi-heure après un nouvel envoi

    Ce qui s'est passé

    L’app est restée en examen pendant plus de dix jours sans bouger. Le développeur l’a soumise à nouveau.

    Résolution

    Elle a été approuvée environ 30 minutes après un nouvel envoi.

    Leçon

    Un examen bloqué n’est pas toujours un verdict sur votre app. Quand il dépasse largement le délai habituel, une nouvelle soumission ou une demande d’examen accéléré peut valoir le coup, mais rien n’est garanti.

52. 

    4.3(a) Spam iOS Directive 4.3

    Sept apps issues d'un template rejetées pour la 4.3 dans la même minute

    Ce qui s'est passé

    Une petite équipe a soumis sept apps basées sur le même template à la review la même semaine. Les sept ont reçu le même rejet pour spam 4.3(a) à la même minute, dont deux apps qui n'avaient jamais été rejetées auparavant. L'équipe en a conclu qu'Apple avait jugé le lot plutôt que chaque app individuellement.

    Résolution

    L'équipe soumet désormais une seule app à la fois.

    Leçon

    Les apps qui partagent une base de code peuvent ressembler à un pattern de spam quand elles arrivent ensemble. Espacez les soumissions et faites en sorte que chaque app se distingue clairement par ses fonctionnalités, son design et ses métadonnées.

53. 

    Règle 2.3.6 iOS Règle 2.3.6

    Rejet pour classification d'âge alors que Connect était déjà conforme

    Ce qui s'est passé

    Une application a été rejetée à cause de sa classification d'âge. Le développeur a ouvert le questionnaire de classification dans App Store Connect et a constaté que chaque réponse correspondait déjà aux exigences du message de rejet.

    Résolution

    Ils n'ont rien changé dans Connect, ont répondu au reviewer que les paramètres étaient déjà conformes, puis ont resoumis l'application. Elle a été approuvée quelques heures plus tard.

    Leçon

    Une note 2.3.6 peut être erronée sur vos paramètres actuels. Vérifiez App Store Connect avant de changer quoi que ce soit et, si tout est déjà conforme, dites-le clairement dans votre réponse plutôt que de tenter un correctif au hasard.

54. 

    Règle 2.1 – Informations requises iOS Directive 2.1

    Historique d'examen limité : enregistrement sur appareil et démo des fonctionnalités payantes

    Ce qui s'est passé

    Une application ayant déjà passé l'examen de Google Play a été renvoyée au titre de la règle 2.1 – Informations requises. Apple a indiqué que le compte développeur avait un historique d'examen limité et a demandé un enregistrement d'écran sur un appareil réel, une démo des fonctionnalités payantes, ainsi qu'une description écrite du fonctionnement de l'app et des services tiers utilisés.

    Résolution

    Le développeur préparait l'enregistrement et les réponses au moment de la publication. Résultat inconnu.

    Leçon

    Réussir l'examen de Google Play ne garantit rien auprès d'Apple. Si votre compte développeur est récent ou a peu de soumissions précédentes, préparez un enregistrement sur un appareil réel, une démo des fonctionnalités payantes et une liste des services tiers avant de soumettre.

55. 

    Directives 2.1, 2.3.2 et 5.2.3 iOS Directive 2.1 Règle 2.3.2 Règle 5.2.3 Téléchargement d'audio et de vidéo Révision sans fin

    Première soumission : 2.1, puis 2.3.2, puis 5.2.3 sur un mois

    Ce qui s'est passé

    La toute première soumission d'un développeur a attendu six jours avant d'être rejetée au titre de la règle 2.1. Il a répondu le jour même. Douze jours plus tard, elle était de nouveau rejetée, cette fois au titre de la 2.3.2. Il a soumis une nouvelle version et, neuf jours plus tard, elle était rejetée au titre de la 5.2.3. Il a de nouveau répondu le jour même et, deux jours plus tard, attendait toujours. Chaque cycle soulevait une règle différente de la précédente.

    Résolution

    Toujours en attente, plus d'un mois après la première soumission.

    Leçon

    Chaque aller-retour peut faire apparaître une nouvelle règle, et chacune peut coûter une semaine ou plus. Avant une première soumission, lisez les règles sur les métadonnées (2.3) et les règles de droits de contenu qui vous concernent (5.2), pas seulement les règles de complétude (2.1), et corrigez tout ce que vous pouvez repérer en un seul build.

56. 

    Règle 4.2 – fonctionnalité minimale iOS Directive 4.2

    Application de prière refusée : assimilée à un livre (règle 4.2)

    Ce qui s'est passé

    Une application de prière et de dévotion religieuse a été rejetée au titre de la règle 4.2, au motif qu'elle était essentiellement un livre. Le développeur a pourtant souligné la présence de fonctionnalités interactives : calendrier, compteur de prières, minuteur de méditation, collections partageables, widgets de l'écran d'accueil et recherche vocale.

    Résolution

    Non précisée.

    Leçon

    Si un évaluateur perçoit votre application comme du contenu statique, les fonctionnalités interactives risquent de ne pas être visibles dans les premières minutes de l'examen. Mettez-les en avant dès les premiers écrans et dans les captures d'écran, et listez-les dans les notes de révision avec les étapes pour accéder à chacune.

57. 

    Règle 2.3.10 iOS Règle 2.3.10

    Treize jours d’attente, rejetée en sept minutes à cause d’Android

    Ce qui s'est passé

    Un développeur a attendu treize jours dans la file d’attente de review, en consultant App Store Connect et ses e-mails chaque jour, et a ouvert deux tickets de support. Quand la review a enfin démarré, l’app a été rejetée environ sept minutes plus tard, car la description sur l’App Store indiquait que le produit fonctionnait dans n’importe quel navigateur sur iPhone ou Android.

    Résolution

    Ils ont supprimé la mention de l'autre plateforme, une modification d'une ligne, et ont resoumis. Résultat pas encore communiqué.

    Leçon

    Apple rejette les métadonnées qui mentionnent d'autres plateformes mobiles. Analysez votre description, vos captures d'écran et vos textes promotionnels avant de soumettre, car une petite erreur de formulation peut vous coûter une attente complète en file d'attente.

58. 

    Règle 5 (Juridique) iOS Règle 5 Juridique

    Rejet lié à la règle 5 concernant OpenAI dans les métadonnées pour la Chine

    Ce qui s'est passé

    Une application d'IA a été rejetée au titre de la Guideline 5 (Legal) car ses métadonnées mentionnaient OpenAI. Apple a expliqué que la Chine exige une licence gouvernementale pour l'IA générative et les services de synthèse profonde, que ChatGPT ne dispose pas de ce permis, et que le développeur doit soit retirer la fonctionnalité d'IA et toute référence à OpenAI ou ChatGPT du nom, du sous-titre, du texte promotionnel, de la description et des captures d'écran pour le store chinois, soit arrêter la distribution en Chine continentale.

    Résolution

    Le développeur recommande de décocher le storefront Chine continentale dans Disponibilité avant de soumettre une app qui mentionne ces services, ce qui permet d'économiser un cycle de review.

    Leçon

    Si votre app s'appuie sur un fournisseur d'IA générative, décidez dès le départ de la disponibilité en Chine. Le rejet concerne le storefront et les métadonnées, pas seulement votre code.

59. 

    Règle 3.1.2 iOS Règle 3.1.2

    Lien vers les conditions d'utilisation dans l'app mais absent de la description

    Ce qui s'est passé

    La première version d'une app d'abonnement a été rejetée deux jours après la soumission, car le lien vers les conditions d'utilisation n'était pas dans la description de l'App Store. Il était déjà présent dans l'app, sur le paywall et dans les réglages, mais pas dans ce champ de métadonnées.

    Résolution

    Le correctif a pris cinq minutes, mais après une nouvelle soumission, le build est resté en « En attente d'examen » pendant plus de dix jours, sans réponse. Aucun cas signalé pour l'instant.

    Leçon

    Pour les abonnements auto-renouvelables, incluez les liens vers les Conditions d’utilisation (EULA) et la Politique de confidentialité dans les métadonnées de l’App Store ainsi que dans l’app avant la première soumission, car un correctif rapide peut encore entraîner une longue seconde attente.

60. 

    Résiliation de compte iOS Résiliation de compte

    Compte résilié (3.2(f)), gains en attente non versés

    Ce qui s'est passé

    Le compte Apple Developer d'un développeur a été résilié en vertu de la section 3.2(f) du Developer Program License Agreement. Près de trois mois plus tard, ses revenus en attente n'avaient toujours pas été versés, et il demandait à d'autres développeurs si quelqu'un avait déjà reçu des revenus retenus après une résiliation.

    Résolution

    Aucun signalement.

    Leçon

    Une résiliation peut geler des revenus déjà acquis, pas seulement les ventes futures. Préservez votre trésorerie, gardez la trace de vos versements et votre propre canal vers les utilisateurs, pour qu'une seule décision de compte ne mette pas fin à votre activité.

61. 

    Directives 2.1 et 5.1.2 iOS Directive 2.1 Règle 5.1.2 Révision sans fin

    Vingt-cinq jours d'examen, puis les directives 2.1 et 5.1.2 d'un seul coup

    Ce qui s'est passé

    Un développeur indépendant a soumis la première version, 1.0, d'une application iOS. Après environ dix-sept jours, le build était toujours en cours d'examen. Au bout d'environ vingt-cinq jours au total, l'App Review l'a rejetée en invoquant la règle 2.1 App Completeness et la règle 5.1.2 Data Use and Sharing dans une même décision. App Store Connect a ensuite bloqué tous les autres éléments de la soumission jusqu'à ce que la version rejetée soit corrigée. Le développeur a précisé que les problèmes cités étaient faciles à corriger ; le plus pénible était de devoir attendre encore deux à trois semaines pour la nouvelle soumission.

    Résolution

    Il a corrigé les deux problèmes et a resoumis. Le résultat de l'examen suivant n'a pas été communiqué.

    Leçon

    Lorsque les files d'attente sont aussi longues, chaque rejet peut coûter des semaines. Avant de soumettre, faites une vérification complète : aucun parcours cassé, un compte de démo fonctionnel, aucun placeholder, et assurez-vous que les réponses relatives à la confidentialité et tout partage de données SDK correspondent exactement à ce que fait réellement l'app.

62. 

    Règle 2.3.1(a) iOS Règle 2.3.1 Métadonnées et IAP

    Refus pour jeux d'argent réel jugés cachés selon la règle 2.3.1(a)

    Ce qui s'est passé

    Un développeur a créé une application de suivi d'habitudes et de discipline où les utilisateurs pouvaient miser de l'argent et le perdre s'ils n'atteignaient pas leurs objectifs. Mi-octobre 2026, l'App Review l'a rejetée au titre de la règle 2.3.1(a), affirmant que l'app contenait des fonctionnalités cachées, notamment la mise en jeu d'argent et la confiscation des mises, non décrites dans les métadonnées. La lettre incluait aussi un avis d'Extended Review, avertissant que des soumissions répétées avec de tels problèmes entraînent des délais de révision plus longs et que les comptes qui enfreignent régulièrement les règles peuvent être retirés de l'Apple Developer Program. L'app a subi cinq rejets au total ; un autre mentionnait un crash pendant la révision sur iPad. Le développeur, qui avait utilisé des outils de codage IA, a résumé les leçons à retenir : lire les guidelines, aligner les métadonnées sur l'app, ne jamais cacher de fonctionnalités ni de collecte de données, vérifier le code généré et tester sur différents appareils.

    Résolution

    Non précisé, hormis la refonte de l'app après cinq rejets. Aucune approbation n'a été signalée.

    Leçon

    Toute fonctionnalité qui implique de l'argent réel, y compris les mises ou les confiscations, doit être clairement indiquée dans la description et les notes pour l'App Review. Testez sur iPad même si vous ciblez l'iPhone, car les réviseurs le font.

63. 

    Règle 4.3(a) iOS Directive 4.3

    Nouvelles fonctionnalités, nouveaux screenshots et une règle 4.3(a) en trois minutes avec un avertissement

    Ce qui s'est passé

    Un développeur qui avait passé environ deux mois à développer une app de zéro s'était déjà vu refuser son projet pour spam (règle 4.3). Pour la tentative suivante, il a ajouté de nouvelles fonctionnalités, remplacé toutes les captures d'écran, optimisé l'app pour plus de tailles d'appareils, puis l'a resoumise avec des notes de review et un compte de test premium. Trois minutes après son passage en review, l'app a été rejetée à nouveau au titre de la règle 4.3(a). Cette fois, le message se terminait par un avertissement de review prolongée : les soumissions répétées présentant ces problèmes entraîneraient des délais de review plus longs, et les comptes qui continuent de soumettre ce type d'apps risquent l'exclusion du programme Apple Developer. Craignant qu'une nouvelle soumission ne fasse perdre tout le compte, le développeur hésitait entre abandonner l'app et demander un appel avec App Review.

    Résolution

    Non résolu au moment de la publication.

    Leçon

    Dès qu'un avertissement de review prolongée apparaît, resoumettre rapidement est le pari le plus risqué. Demandez d'abord un appel avec App Review et ne resoumettez qu'une fois que vous saurez ce qu'ils considèrent comme trop similaire.

64. 

    Règle 4.3(b) iOS Directive 4.3

    Rejetée en trois minutes, puis trois semaines de silence après l'appel

    Ce qui s'est passé

    L'app d'un développeur a été rejetée au titre de la directive 4.3(b) environ trois minutes après son entrée en revue. Il a fait appel auprès de l'App Review Board. Trois semaines plus tard, il n'avait toujours aucune réponse, aucun changement de statut et aucun message d'aucune sorte.

    Résolution

    Non résolu.

    Leçon

    Un appel peut rester des semaines sans retour. Travaillez en parallèle sur ce qui différencie votre app dans une catégorie saturée, pour ne pas rester bloqué à attendre l'appel.

65. 

    Résiliation de compte iOS Résiliation de compte

    Une app ressemblait à un site web, et des dizaines d'apps ont disparu

    Ce qui s'est passé

    Un studio qui avait publié des applications depuis plus d’une décennie, plus de 80 au total, a vu son compte développeur signalé pour résiliation. Selon le studio, la raison invoquée était qu’une de ses applications pouvait être considérée comme similaire à un site web existant. Il n’y a eu ni avertissement ni possibilité de retirer uniquement cette application. Toutes ses applications ont été retirées de l’App Store, y compris des applications licenciées sans rapport, développées pour des clients, et les mises à jour ont été bloquées.

    Résolution

    Non résolu. Le studio a publiquement contesté la décision.

    Leçon

    Un compte développeur est un point de défaillance unique. Si vous compilez des applications pour des clients, publiez-les sous le compte développeur du client afin qu’un litige concernant l’une de vos applications ne puisse pas entraîner la suppression des leurs.

66. 

    Section 3.2(f) (contrat de licence du programme Apple Developer) iOS Résiliation de compte

    Un titre mis à jour, puis une notification de résiliation 3.2(f)

    Ce qui s'est passé

    Un développeur indépendant a envoyé un simple changement de titre pour une application et a reçu un avis de résiliation au titre de la section 3.2(f). Toutes ses applications ont été retirées du store. Il a déposé des recours officiels et, 15 jours plus tard, n'avait toujours pas eu de réponse d'une personne.

    Résolution

    Non résolu.

    Leçon

    La mise à jour qui déclenche un avis 3.2(f) n'est peut-être pas ce qui a fait réagir Apple. Avant de faire un recours, rassemblez des preuves claires de la propriété et de la gestion de chaque application, et attendez-vous à plusieurs semaines avant une réponse.

67. 

    Section 3.2(f) (contrat de licence du programme Apple Developer) iOS Résiliation de compte

    Une correction de paywall, puis un avis de résiliation 3.2(f) une semaine plus tard

    Ce qui s'est passé

    L'application d'un développeur indépendant avait été rejetée une fois, à cause de l'affichage des prix annuels et hebdomadaires sur son paywall. Ce paywall provenait d'un template copié par un assistant IA de code. Ils l'ont corrigé dans code, ont soumis un nouveau build et ont attendu environ une semaine. Au lieu du résultat de la revue, ils se sont réveillés avec un avis de résiliation en attente au titre de la section 3.2(f). Tout leur compte développeur a été signalé, chaque application qu'ils avaient construite au fil des années a été retirée de l'App Store, et les paiements ont été gelés. Le développeur a affirmé n'avoir rien changé à l'app après la soumission, avoir des logs pour le prouver, et a demandé publiquement si quelqu'un avait déjà récupéré un compte.

    Résolution

    Non résolu au moment de la publication.

    Leçon

    Considérez un rejet lié au paywall ou aux tarifs comme un avertissement, pas comme une simple formalité. Avant la première soumission, vérifiez comment les prix et les conditions d'essai sont affichés dans tout template ou paywall généré par code, et conservez vos logs de build et de changements pour pouvoir documenter exactement ce que vous avez soumis si votre compte est un jour remis en question.

68. 

    Règle 3.1.1 : achats intégrés machine macOS Directive 3.1.1

    Un client de cloud gaming gratuit refusé selon la règle 3.1.1 pour des achats dans les jeux en streaming

    Ce qui s'est passé

    Un développeur a créé une application gratuite de jeu à distance pour le service de cloud gaming d'un grand constructeur de consoles, et l'a soumise à l'App Store. La version Mac a été rejetée au titre de la directive 3.1.1. L'App Review a estimé que certains jeux en streaming pourraient amener les utilisateurs à acheter du contenu numérique en dehors de l'App Store. D'après ce qu'en a compris le développeur, le service ne permet pas aux joueurs de finaliser un paiement pendant une session de streaming : certains jeux affichent des options d'achat, mais le paiement ne peut pas aboutir pendant le streaming. Il a fait valoir que plusieurs applications de streaming similaires étaient déjà présentes sur le store et a déposé un recours.

    Résolution

    Recours en attente au moment de la publication.

    Leçon

    Pour les applications de streaming et les applications clientes, l'App Review juge ce que les utilisateurs voient dans le contenu en streaming, pas seulement votre propre code. Expliquez précisément dans les notes de review comment se comportent les achats pendant le stream, captures d'écran à l'appui, dès la première soumission plutôt que de garder ça pour le recours.

69. 

    Connexion sur iPad (numéro de directive non précisé) iOS Connexion

    Troisième rejet : la connexion a échoué sur iPad pendant une panne de backend

    Ce qui s'est passé

    Une petite équipe qui développe une app de fitness a vu son app iOS rejetée pour la troisième fois : le relecteur n'arrivait pas à se connecter sur un iPad. La cause ne venait pas de l'app code : leur fournisseur de backend avait des problèmes d'authentification au moment où le relecteur a essayé, la connexion a donc simplement échoué. L'équipe avait fourni un compte de démo avec e-mail et mot de passe, mais d'après elle, le relecteur n'a pas réessayé plus tard. Elle ne disposait ni d'un iPad ni d'un Mac pour tester. Une fois le backend rétabli, elle a soumis l'app à nouveau. Apple leur avait dit que l'app resterait en examen accéléré même en cas de nouveau rejet, et pourtant, trois jours ouvrés plus tard, elle était toujours en attente d'examen.

    Résolution

    Soumise à nouveau, toujours en attente d'examen au moment de la publication.

    Leçon

    Les relecteurs testent souvent sur iPad et ne testent généralement votre connexion qu'une seule fois. Surveillez l'état de votre backend et de votre fournisseur d'authentification pendant qu'un build est en cours d'examen, testez le compte de démo sur un écran de la taille d'un iPad avant de soumettre, et indiquez dans les notes de révision qui contacter si la connexion échoue.

70. 

    Directives 5.1.1(i) et 5.1.2(i) iOS Règle 5.1.1 Règle 5.1.2 Partage de données avec l'IA

    Le consentement IA noyé dans les CGU ne suffisait pas pour les règles 5.1.1(i) et 5.1.2(i)

    Ce qui s'est passé

    L'app de journal d'un développeur a été rejetée sur iOS au titre des directives 5.1.1(i) et 5.1.2(i), qui portent toutes deux sur le partage de données utilisateur avec des services d'IA. Le consentement pour ce traitement était déjà prévu dans les conditions de l'app, mais l'App Review ne l'a pas accepté. Le développeur a déplacé le consentement sur un écran explicite dans l'app, affiché en premier, avant qu'un modèle ne lise la moindre entrée. Il a ensuite cartographié chaque chemin code où les entrées atteignent un modèl’et a conditionné chacun à ce consentement, afin qu'aucune requête ne soit même construite sans un « oui ». Les jobs en arrière-plan ignorent désormais les comptes qui n'ont pas accepté et attendent au lieu d'échouer, et une vérification de release échoue si l'app appelle un hôte d'IA que l'écran de consentement ne nomme pas.

    Résolution

    Corrigé et soumis à nouveau. Le verdict d'Apple était encore inconnu au moment de la publication.

    Leçon

    Une ligne dans vos CGU ne constitue pas un consentement pour le partage de données avec l'IA. Demandez-le dans l'app avant la première requête, nommez le fournisseur et les données, et assurez-vous que chaque chemin code qui envoie du contenu utilisateur vérifie cette réponse.

71. 

    Section 3.2(f) (Developer Program License Agreement), après des rejets répétés liés aux métadonnées iOS Résiliation de compte Métadonnées et IAP

    Une nouvelle librairie, huit refus, une app rebaptisée, puis un avis de résiliation

    Ce qui s'est passé

    Un développeur indépendant avait une application iOS de presque trois ans, qui avait généré un chiffre d'affaires à six chiffres, et il avait publié de nombreuses mises à jour avec un faible taux de remboursement. Il y a plus de six mois, il a soumis une petite mise à jour dont le seul changement était l'ajout d'une nouvelle librairie. L'App Review l'a rejetée plus de huit fois, à chaque fois pour des questions de métadonnées : des mots-clés en ligne depuis plus d'un an, un sous-titre dans une localisation, puis les captures d'écran, puis les mêmes points à nouveau, et enfin le nom de l'application lui-même, qui représentait l'essentiel de son trafic de recherche. Il a demandé un appel avec l'App Review, et l'évaluateur lui a dit que le nom était le dernier problème restant. Il a renommé toute l'application et l'a soumise à nouveau. Trois jours plus tard, un refus générique est revenu avec de nouveau les problèmes de sous-titre et de captures d'écran. Il a décidé que la mise à jour n'était pas nécessaire et l'a abandonnée. Des mois plus tard, un avis de résiliation en attente est arrivé dans ce même ancien fil de discussion. Il indiquait que le compte avait violé les directives à plusieurs reprises pour tenter de contourner le processus de review et que les problèmes soulevés dans les messages précédents n'avaient pas été résolus. L'application a été retirée du store et l'ensemble du compte a été signalé pour suppression.

    Résolution

    Recours déposé auprès de l'App Review Board, en attente au moment de la publication.

    Leçon

    Une soumission abandonnée peut quand même pénaliser votre compte. Si une boucle de review s'installe, faites confirmer par écrit chaque problème restant dans le fil de la review, et pas seulement lors d'un appel. Si vous décidez d'abandonner une mise à jour, répondez dans le fil pour le dire et retirez le build de la review au lieu de laisser le rejet en suspens.

72. 

    Guideline 1.1 Safety: Objectionable Content, puis la section 3.2(f) iOS Contenu répréhensible Résiliation de compte

    Deux rejets 1.1, une question sur l'image à utiliser, puis un avis de résiliation

    Ce qui s'est passé

    L’application iOS d’un développeur, qui générait des photos de couples par IA, a été rejetée au titre de la règle 1.1 pour contenu répréhensible. Le rejet ne précisait pas quelle image posait problème. Il a adouci les images d’exemple, sans contact ni rapprochement, puis a resoumis l’application une fois, environ cinq jours plus tard. Quatre jours après, elle a été rejetée à nouveau pour la même raison. Plutôt que d’envoyer un autre build, il a écrit à Apple pour demander quelle image était en cause. Une dizaine de jours se sont écoulés sans réponse, puis l’application a été retirée du store et le développeur a reçu un avis de résiliation imminent. Selon sa compréhension, Apple a interprété ce cycle répété de corrections et de resoumissions comme une tentative de contourner la revue. Les versements ont été suspendus et toutes les applications du compte étaient menacées, avec 30 jours pour faire recours. En lisant des fils de forum de développeurs ayant reçu le même avis, il a constaté que la plupart des recours restaient sans réponse pendant des semaines, et que le seul rétablissement qu’il ait trouvé est intervenu après un second recours qui indiquait la cause réelle et divulguait tout le reste.

    Résolution

    Préparation d’un recours au moment de la publication.

    Leçon

    Deux rejets au titre de la même règle peuvent désormais suffire à mettre un compte en danger. Quand un rejet pour contenu est vague, demandez à App Review de pointer l’écran ou la ressource exacte avant de resoumettre, conservez une trace de chaque modification, et considérez le second rejet comme un signal pour faire une pause plutôt que de réessayer.

73. 

    Directives 2.3.7, 5.2.5 et 4.8 iOS Directive 2.3.7 Métadonnées et IAP Connexion obligatoire

    Approuvé sur Mac, puis rejeté sur iPhone au titre des directives 2.3.7, 5.2.5 et 4.8 pour la même app

    Ce qui s'est passé

    Un développeur qui créait un client de calendrier pour un service tiers majeur a d'abord publié la version Mac. La version Mac avait déjà nécessité un recours formel juste pour indiquer dans sa fiche qu'elle fonctionnait avec ce service de calendrier, et il avait déjà expliqué à l'App Review pourquoi Sign in with Apple n'était pas nécessaire. Quand il a ajouté la version iPhone, sous le même bundle et le même App ID que l'app Mac, elle a été rejetée sur trois directives à la fois : 2.3.7 pour des prix affichés dans un événement in-app, 5.2.5 pour une ligne indiquant que l'app était pour iPhone, iPad et Mac, et 4.8 pour ne pas proposer Sign in with Apple à côté de la connexion propre au service de calendrier. La directive 4.8 prévoit une exception pour les apps qui sont clients d'un service tiers spécifique, ce qui est le cas ici, mais l'explication fournie pour la version Mac n'a pas été reprise. Chaque cible de plateforme a été examinée à partir de zéro.

    Résolution

    Non précisé au moment de la publication.

    Leçon

    Une nouvelle plateforme, c'est un nouvel examen, même au sein du même App ID. Copiez dans les notes de review de chaque plateforme toutes les explications et exceptions que vous avez déjà obtenues, et vérifiez les prix et les noms d'appareils Apple dans les événements in-app et les descriptions avant de soumettre.

74. 

    Directive 3.1.2(c), puis la marque Apple dans un texte Siri (numéro de directive non précisé) iOS Règle 3.1.2 Révision sans fin

    Neuf jours d'attente, un refus pour paywall (3.1.2(c)), puis un binaire rejeté en 42 secondes à cause d'un texte Siri

    Ce qui s'est passé

    Un développeur sur un nouveau compte a soumis la première version d'une application de suivi d'écriture et a attendu environ neuf jours avant qu'elle passe en « In Review ». Cinquante minutes plus tard, elle était rejetée au titre de la directive 3.1.2(c) : sur le plan annuel, le prix mensuel calculé s'affichait dans une taille de police plus grande que le prix annuel réellement facturé. Il a corrigé les tailles de police du paywall et envoyé un nouveau build. Ce build a été rejeté automatiquement en 42 secondes, car le texte d'aide d'un raccourci Siri mentionnait une application Apple par son nom de marque, et le texte des intents Siri ne peut pas contenir le mot Apple. Il l'a reformulé pour désigner l'application de notes de façon générique et a renvoyé le build.

    Résolution

    Soumis à nouveau, résultat inconnu au moment de la publication.

    Leçon

    Avant la première soumission, faites du montant facturé le prix le plus visible sur chaque plan et recherchez les marques d'Apple dans toutes les chaînes visibles par l'utilisateur, y compris Siri, Raccourcis et les textes des widgets. Les contrôles automatisés les détectent en quelques secondes, mais chaque passage vous coûte encore une place dans la file d'attente.

75. 

    Section 3.2(f) (Developer Program License Agreement), citant un ancien rejet de nom iOS Résiliation de compte Métadonnées et IAP

    Un refus de nom corrigé et approuvé, puis un avis de résiliation pour fraude près d’un an plus tard

    Ce qui s'est passé

    Un développeur solo gérant un petit compte d'entreprise avait développé huit applications en production en un an et demi environ. Presque un an plus tôt, l'une de ces applications avait été rejetée parce qu'Apple contestait un mot dans son nom. Le développeur a changé le nom, l'application a été examinée de nouveau et approuvée, puis une mise à jour ultérieure a aussi été approuvée. L'historique d'examen qu'il a partagé montre la version 1.0 rejetée deux jours de suite et approuvée le lendemain, puis une mise à jour approuvée du premier coup environ deux mois plus tard. Ensuite, l'application est restée sans modification pendant environ neuf mois. Puis une nouvelle application du même compte a été rejetée, et un avis de résiliation en cours est arrivé, invoquant une activité malhonnête ou frauduleuse au titre de la section 3.2(f) : les soumissions avaient violé les directives à répétition pour tenter d'échapper à l'examen, et les problèmes évoqués dans les messages précédents restaient non résolus. Il ne citait aucun nouveau problème et n'était précédé d'aucun avertissement ni d'aucune question. Les revenus de toutes les applications ont été suspendus, y compris celles qui n'avaient jamais posé problème, et l'avis prévenait qu'un nouveau compte pourrait lui aussi être résilié. La seule façon de répondre était un formulaire web limité à 2 000 caractères, qui renvoyait un accusé de réception automatisé, puis plus rien. Le développeur a accepté le retrait des applications signalées, a éteint ses serveurs le jour même, a suspendu toutes les soumissions et a envoyé un recours complet dès le premier jour.

    Résolution

    Recours envoyé dès le premier jour, seul un accusé de réception automatisé au moment de la publication.

    Leçon

    Un refus que vous avez corrigé et qui a ensuite été approuvé peut encore être cité des mois plus tard comme preuve d'un comportement récurrent. Conservez chaque message de refus, la modification exacte que vous avez apportée et l'approbation qui a suivi, pour pouvoir présenter l'historique complet dans un court formulaire de recours — et ne vous attendez à aucun délai annoncé une fois le formulaire envoyé.

76. 

    Guidelines 4.3 Spam et 4.2.6 iOS Directive 4.3 Règle 4.2.6

    Un jeu développé en solo, rejeté deux fois pour spam et pour template, neuf réponses envoyées, aucune réponse en retour

    Ce qui s'est passé

    Un développeur qui crée des jeux seul le soir a soumis un jeu original, rejeté deux fois à quatre jours d'intervalle début octobre, au titre de la guideline 4.3 pour spam et de la guideline 4.2.6, qui couvre les apps créées à partir d'un template commercialisé ou d'un service de génération d'apps. Aucun template n'entrait en jeu et chaque ligne de code avait été écrite par le développeur. Les deux refus reprenaient le même texte type, et aucun ne nommait l'app à laquelle le jeu était censé ressembler. Apple a ensuite envoyé neuf questions sur la façon dont le jeu avait été créé, et le développeur y a répondu en détail dès le lendemain du second refus. Aucune réponse n'est arrivée. Environ neuf jours plus tard, il a déposé un recours auprès de l'App Review Board, et une semaine après, il attendait toujours. Son hypothèse : une personne qui publie plusieurs jeux en quelques mois ressemble à une usine à apps du point de vue du reviewer. En attendant, il a rendu le jeu jouable gratuitement dans un navigateur web.

    Résolution

    Recours auprès du comité de l’App Store en attente au moment de la publication, environ trois semaines après le premier refus.

    Leçon

    Les directives 4.3 et 4.2.6 peuvent être appliquées à l’ensemble de votre compte, pas seulement à un seul binaire. Si vous publiez plusieurs titres en peu de temps, montrez ce qui rend chacun original dès la première soumission, avec des notes de révision sur la façon dont il a été construit et une courte vidéo de gameplay, car une fois le texte de refus standardisé, des réponses détaillées peuvent rester sans réponse pendant des semaines.

77. 

    Directive 2.1 (complétude de l’application), puis directive 5 (juridique, disponibilité en Chine) iOS Directive 2.1 Règle 5 Juridique Révision sans fin

    Une licence gratuite pour le réviseur a masqué le paywall, puis six jours d’attente et un refus lié à l’IA en Chine

    Ce qui s'est passé

    Un développeur a soumis sa première app iOS, un outil de finances personnelles pour suivre les paiements récurrents, et elle a été rejetée au titre de la règle 2.1 Intégralité de l'app. La cause était une faveur qui s'est retournée contre lui : il avait attribué une licence payante à l'adresse e-mail du relecteur, qui a donc contourné le paywall et n'a jamais vu le parcours d'achat. Le développeur a rédigé un guide PDF pas à pas avec des captures d'écran pour le relecteur et a soumis à nouveau, en envoyant cette fois les versions iOS et Mac ensemble. La nouvelle soumission a attendu six jours avant de passer en « In Review », puis a été rejetée de nouveau, cette fois à cause d'une mention de ChatGPT alors que l'app était disponible en Chine continentale.

    Résolution

    Toujours rejetée au moment de la publication, alors qu'un build plus récent était proposé aux testeurs via TestFlight.

    Leçon

    Laissez l'App Review voir exactement ce que voit un nouvel utilisateur, paywall inclus. Donnez au relecteur une démo fonctionnelle ou un compte sandbox et des notes claires plutôt qu'une licence gratuite qui masque le parcours d'achat. Si l'app ou sa fiche mentionne un fournisseur d'IA comme ChatGPT, vérifiez si la Chine continentale figure dans votre zone de disponibilité avant de soumettre, car chaque nouveau passage peut coûter des jours dans la file d'attente.

78. 

    Règle 2.3.10 Métadonnées exactes iOS Règle 2.3.10 Métadonnées et IAP Révision sans fin

    Dix jours pour une première review, une mention de Google Play, puis deux semaines d'attente supplémentaires

    Ce qui s'est passé

    Un développeur avec un tout nouveau compte développeur a soumis une application toute neuve début octobre. C'est une app où les utilisateurs peuvent envoyer publiquement leurs propres images, ce qui, selon le développeur, devait attirer un examen plus poussé de la modération de contenu. La première review est arrivée dix jours plus tard, sur un iPad, et s'est soldée par un rejet au titre de la directive 2.3.10 Accurate Metadata : l'app ou ses métadonnées mentionnaient une plateforme tierce, et l'étape suivante consistait à supprimer les références à Google Play. Le développeur a retrouvé la mention dans le texte décrivant un achat intégré. Après correction, l'app est retournée dans la file d'attente, et deux semaines plus tard, elle attendait toujours sa review, 24 jours après la première soumission et toujours pas en ligne.

    Résolution

    Toujours en attente de review au moment de la rédaction, 24 jours après la première soumission.

    Leçon

    Vérifiez chaque champ de texte que vous soumettez, y compris les descriptions d'achats intégrés, pour y chercher les noms d'autres stores et plateformes avant la première soumission. Sur un nouveau compte, chaque aller-retour peut coûter une semaine ou plus dans la file d'attente : une mention d'un seul mot peut retarder un lancement de plusieurs semaines.

79. 

    Directive 2.1 App Completeness (Information Needed) iOS Directive 2.1 Révision sans fin

    24 jours d'attente, puis un rejet 2.1 demandant un enregistrement d'écran complet

    Ce qui s'est passé

    Un développeur a soumis la version 1.0.0 d'une nouvelle app iOS avec un groupe d'abonnements et deux abonnements, annuel et mensuel. Après 24 jours d'attente, Apple l'a examinée et l'a rejetée au titre de la directive 2.1 App Completeness, ce qui a laissé le développeur perplexe. Comme la version de l'app a été rejetée, les abonnements soumis avec elle n'ont pas pu être approuvés non plus et sont restés au statut Ready for Review. Le motif du rejet était une demande « 2.1 Information Needed », la première que le développeur recevait. Elle demandait un enregistrement d'écran sur un appareil physique sous la dernière version du système d'exploitation, depuis le lancement et montrant le parcours utilisateur typique : inscription, connexion et suppression de compte, tout contenu généré par l'utilisateur avec ses outils de signalement et de blocage, et l'accès au contenu payant. Elle demandait aussi une description de l'objectif et du public cible, des instructions de configuration avec les identifiants de connexion, une liste des services externes utilisés par l'app, services d'IA inclus, les éventuelles différences régionales, et la documentation pour les secteurs réglementés ou les contenus tiers protégés. Les réponses devaient aussi être ajoutées aux notes de révision dans App Store Connect pour les futures soumissions.

    Résolution

    Le développeur s'est remis à préparer l'enregistrement et les réponses au moment de la rédaction. Issue inconnue.

    Leçon

    Une demande « Information Needed » après des semaines dans la file d'attente impose un nouveau cycle complet de révision. Enregistrez cette démonstration sur un appareil réel et rédigez ces réponses dans les notes de révision avant de soumettre une nouvelle app, surtout si elle contient des abonnements, des comptes ou du contenu utilisateur, car une version rejetée bloque aussi tout ce qui est soumis avec elle.

80. 

    Section 3.2(f) (contrat de licence du programme Apple Developer) Programme Apple Developer Résiliation de compte Révision sans fin

    Six mises à jour approuvées d'affilée, puis une mise à jour de routine et une résiliation 3.2(f)

    Ce qui s'est passé

    Un développeur indépendant a obtenu six mises à jour approuvées d'affilée. L'historique de révision qu'il a partagé montre la dernière soumission « In Review » et toutes les précédentes marquées « Review Completed ». Il a ensuite soumis une mise à jour de routine à la mi-octobre, restée bloquée en révision. Au lieu d'un résultat de révision, c'est tout le compte développeur qui a été résilié en vertu de la section 3.2(f). Dans App Store Connect, un message daté du jour de cette soumission était rattaché à plusieurs versions et marqué comme problèmes non résolus. Le développeur a décrit ses apps comme natives, avec un historique impeccable de mises à jour approuvées, et indiqué que le support Apple examinait son recours.

    Résolution

    Recours en cours d'examen au moment de la publication.

    Leçon

    Une série d’approbations sans accroc ne protège pas d’une résiliation 3.2(f). Conservez un historique daté de chaque soumission, message de review et approbation, et vérifiez la section Messages dans App Store Connect après chaque review, pour pouvoir envoyer l’historique complet dès qu’un recours est possible.

81. 

    Demande d’informations d’App Review (compte démo et enregistrement d’écran) iOS Connexion

    Le compte démo supprimé cinq minutes après la soumission, puis une demande d’enregistrement qui a évité un second refus

    Ce qui s'est passé

    Une agence a soumis l’application d’un client avec un compte démo pour App Review. Cinq minutes après la soumission, App Review avait supprimé ce compte démo. Apple a ensuite demandé un enregistrement d’écran de l’application. Pendant l’enregistrement, l’équipe a repéré dans l’application un texte commercial qu’elle avait laissé passer et qui aurait provoqué un nouveau refus.

    Résolution

    Résultat final non communiqué au moment de la publication.

    Leçon

    Un reviewer peut supprimer le compte de démo que vous fournissez, par exemple en vérifiant que la suppression de compte fonctionne ; prévoyez donc un moyen de le recréer ou fournissez-en plusieurs. Enregistrez votre propre parcours de review avant de soumettre : regarder l'app comme le fait un reviewer est un moyen peu coûteux de repérer les textes qui déclencheraient le prochain refus.

82. 

    Section 3.2(f) (contrat de licence du programme Apple Developer) Programme Apple Developer Résiliation de compte Métadonnées et IAP

    Cinq refus initiaux, quatre mises à jour approuvées, puis un avis 3.2(f) plus d'un an après

    Ce qui s'est passé

    Un développeur iOS indépendant, avec presque dix ans d’applications derrière lui, a soumis une nouvelle application IA de génération de vidéos à partir d’images en avril 2025. Les utilisateurs envoyaient leurs propres photos, obtenaient leur première génération gratuitement, puis pouvaient acheter des crédits via des achats in-app à usage unique, sans abonnement. La première soumission a été rejetée cinq fois, principalement à cause des captures d’écran et des métadonnées : des captures jugées trop orientées marketing, et une capture montrant un couple qui s’embrasse, puis celle qui l’a remplacée, montrant une demande en mariage, toutes deux signalées au titre de la directive « Contenu choquant ». Après modification des captures d’écran, de leurs textes et du build, l’application a été approuvée, et quatre mises à jour ont suivi sans aucun rejet, la dernière en août 2025. Aucune mise à jour n’a été soumise depuis. Plus de quatorze mois plus tard, un avis de résiliation en attente est arrivé, indiquant que les soumissions du compte avaient enfreint les directives à plusieurs reprises pour tenter d’échapper à la revue, avec des violations toujours non résolues après plusieurs nouvelles soumissions, et il était joint aux cinq versions. Le développeur a déclaré qu’App Store Connect n’affichait plus assez de détails pour reconstituer les anciens rejets. Il a fait appel environ 30 minutes après la réception de l’avis, vers minuit, dans la limite de 2 000 caractères, et a ensuite regretté de ne pas avoir attendu pour le rédiger plus clairement.

    Résolution

    Recours en attente au moment de la publication.

    Leçon

    Une approbation ne clôt pas le dossier. Conservez votre propre copie de chaque message de rejet, de la directive citée, des modifications apportées et de la date d’approbation, car App Store Connect peut ne plus afficher les anciens détails par la suite. Si vous recevez un avis, prenez le temps de rédiger un recours clair respectant la limite de caractères plutôt que d’en envoyer un dans la première heure.

83. 

    Section 3.2(f) (contrat de licence du programme Apple Developer) Programme Apple Developer Résiliation de compte Métadonnées et IAP

    Un mot-clé dans le titre, une résiliation 3.2(f) et une réponse d’appel renvoyant vers des références de streaming

    Ce qui s'est passé

    Un développeur indépendant a vu son compte développeur entier résilié au titre de la section 3.2(f). Selon lui, cela s’est fait sans avertissement ni rejet de métadonnées antérieur, et il pensait que la cause était une erreur de mot-clé dans le titre d’une application. Il a déposé un recours. L’App Review Board a répondu que son enquête confirmait des violations des directives : l’une des applications du développeur contenait des références trompeuses qui laissaient croire aux utilisateurs qu’elle proposait des services de streaming, ce qu’Apple a qualifié d’inadmissible. La lettre décrivait une série de comportements manipulateurs ou trompeurs, maintenait les paiements de revenus suspendus et indiquait que, une fois la résiliation formalisée, le développeur pouvait demander sa réintégration à l’App Review Board, en expliquant les motifs et les améliorations prévues.

    Résolution

    Recours rejeté. Une demande de réintégration est possible après une résiliation formelle.

    Leçon

    Des mots dans un titre ou des mots-clés qui évoquent un service que l’app ne propose pas, comme le streaming, peuvent être lus comme trompeurs plutôt que comme une simple erreur de métadonnées, et mener directement à une résiliation sans rejet préalable. Vérifiez chaque titre, sous-titre et mot-clé par rapport à ce que fait réellement l’app avant de soumettre.

84. 

    Directive 4.1(a) Copycats iOS Révision sans fin

    15 jours en revue, puis un 4.1(a) pour des contrefaçons d’affiches de films issues d’un API public

    Ce qui s'est passé

    Un développeur a créé une app iOS qui aide les gens à choisir un film. Elle affiche des titres et des affiches tirés d’une base de données de films publique API, créditée dans l’app, et son bouton « Regarder » ouvre l’app de streaming officielle sans rien diffuser elle-même. Après 15 jours de review, Apple l’a rejetée au titre de la directive 4.1(a) Copycats, considérant les affiches comme du contenu tiers et demandant la preuve des droits d’utilisation, ou leur suppression. La même app avec les mêmes affiches avait été approuvée sur Android et sur un store d’apps pour TV.

    Résolution

    Non résolu au moment de la publication. Le développeur demandait à d'autres développeurs si les conditions API avaient été acceptées comme preuve ou si les affiches devaient être retirées.

    Leçon

    Les crédits dans l'application et l'approbation sur d'autres stores ne comptent pas comme des droits pour l'App Review. Si votre application affiche des affiches, des visuels ou des logos d'un API, préparez une preuve écrite de votre droit de les afficher avant de soumettre, ou prévoyez une version sans ces éléments.

85. 

    Rejet des métadonnées (mot-clé localisé) iOS Métadonnées et IAP

    L'IA a traduit l'application en cinq langues et a glissé un mot-clé qui a entraîné son rejet

    Ce qui s'est passé

    Un développeur a utilisé un modèle d'IA pour traduire son application en cinq langues supplémentaires. Dans l'une de ces langues, la traduction a ajouté un mot-clé susceptible d'être mal interprété, et la soumission a été rejetée à cause de cela. Une semaine plus tard, le développeur attendait toujours une réponse et, après une semaine de témoignages d'autres développeurs sur des résiliations 3.2(f), il craignait qu'une correction même approuvée puisse ensuite être retenue contre le compte.

    Résolution

    En attente d’une réponse d’Apple au moment de la publication.

    Leçon

    Faites relire chaque mot-clé, titre et sous-titre localisé par quelqu’un qui maîtrise la langue avant de soumettre. La traduction automatique est rapide, mais l’App Review évalue les mots de chaque locale comme si vous les aviez choisis vous-même.

86. 

    Métadonnées de l’aperçu de l’app (référence au prix) iOS Métadonnées et IAP

    Un aperçu de l’app indiquait « essai gratuit disponible » et la mise à jour a été rejetée

    Ce qui s'est passé

    Un développeur indépendant a soumis une mise à jour dont la vidéo d’aperçu de l’app contenait la mention « essai gratuit disponible ». Apple a rejeté la mise à jour, considérant toute référence à « gratuit » dans l’aperçu comme une référence au prix. Le développeur a remonté la vidéo et l’a soumise à nouveau.

    Résolution

    Vidéo remontée et soumise à nouveau. Résultat final non communiqué au moment de la publication.

    Leçon

    Évitez d’afficher les prix ou le mot « gratuit » dans les aperçus de l’app, même si l’essai est réel. Présentez plutôt les conditions de l’essai dans l’app, sur le paywall.

87. 

    Directive 2.5.1 Exigences logicielles (HealthKit) iOS Révision sans fin

    Six jours d’attente, puis un refus 2.5.1 car la synchronisation Health n’avait pas le badge Apple Health

    Ce qui s'est passé

    Un développeur indépendant a soumis une mise à jour majeure ajoutant pour la première fois la synchronisation avec Apple Health. Elle est restée six jours en attente d’examen. C’est seulement alors qu’il a remarqué qu’un nouvel accord développeur attendait d’être signé sur son compte. Il l’a signé, et la mise à jour est passée en examen l’après-midi même, même s’il ne pouvait pas dire si les deux étaient liés. La mise à jour a ensuite été rejetée au titre de la directive 2.5.1, car la fonctionnalité Health n’était pas clairement identifiée dans l’interface de l’app. Le développeur ne connaissait pas le badge Apple Health.

    Résolution

    Ajout du badge Works with Apple Health à côté du toggle de synchronisation, d'une note pour la review et d'un enregistrement d'écran fait sur un appareil réel. Approuvée à la soumission suivante.

    Leçon

    Si votre application lit ou écrit des données de santé, affichez-le clairement dans l'interface avec le badge Apple Health dès la première soumission. Et si une review traîne pendant des jours, vérifiez d'abord sur App Store Connect qu'un accord n'est pas resté non signé.

88. 

    Directive 1.1 Contenu répréhensible iOS Contenu répréhensible

    Plus d'un an sans aucun refus, puis supprimé pour la règle 1.1 sans aucun préavis

    Ce qui s'est passé

    Un développeur indépendant avait une application sur l'App Store depuis plus d'un an. Elle n'avait jamais été rejetée et rapportait un modeste revenu d'abonnement mensuel. Sans le moindre avertissement préalable, Apple a envoyé un message indiquant que l'application avait été retirée du store pour violation de la directive 1.1 Contenu répréhensible.

    Résolution

    Le développeur a dit à Apple qu’il ne resoumettrait pas, a abandonné l’app et toute la niche, car il ne voulait pas risquer son compte développeur.

    Leçon

    Un historique de validation irréprochable ne protège pas une app d’un retrait ultérieur, et les règles de contenu peuvent s’appliquer à une app validée depuis longtemps. Si votre app est dans une niche sensible, vérifiez son contenu et ses captures d’écran au regard de la directive 1.1 maintenant, pas après un avis de retrait.

89. 

    Refus pour bug (directive non précisée) iOS Révision sans fin

    Un timeout de matchmaking de 100 secondes signalé comme un bug, puis six jours d’attente pour une réponse

    Ce qui s'est passé

    Un développeur a soumis un jeu multijoueur. Le reviewer l’a refusé pour un bug, mais ce qu’il a rencontré n’était pas un crash : le jeu cesse de chercher après 100 secondes d’attente pour appairer le joueur avec un adversaire, et le reviewer a vu dans ce timeout un comportement défectueux. Le développeur a répondu au reviewer pour expliquer le fonctionnement du matchmaking et a aussi retiré le timeout du jeu. Six jours plus tard, il n’avait toujours pas eu la moindre réponse.

    Résolution

    Expliqué dans une réponse et le timeout a été retiré. Toujours en attente d’une réponse au moment de la publication.

    Leçon

    Un reviewer joue souvent seul et à une heure inhabituelle, donc une file de matchmaking vide est probable. Donnez à l’équipe de review un moyen d’accéder à une vraie partie, comme un adversaire bot ou un mode démo, et expliquez-le dans les notes de review avant de soumettre.

90. 

    Rejet des métadonnées (liens Conditions et Confidentialité) iOS Métadonnées et IAP

    Code réutilisé depuis une autre app, et les liens Conditions et Confidentialité pointaient encore vers l’ancienne

    Ce qui s'est passé

    Un développeur a créé une nouvelle app en réutilisant en partie des éléments d’une de ses apps précédentes. Les liens vers les Conditions d’utilisation et la Politique de confidentialité qu’elle contient pointaient encore vers l’ancienne app, et l’App Review a rejeté la soumission pour cette raison. Le développeur a indiqué que le message de rejet précisait exactement ce qui devait être modifié.

    Résolution

    J’ai corrigé les liens et resoumis l’application. Le développeur a indiqué qu’une revue accélérée est généralement traitée en une journée, mais qu’il faut l’utiliser avec parcimonie.

    Leçon

    Avant de soumettre une application issue d’un ancien projet, vérifiez chaque lien, le nom du bundle et les pages légales reprises. Lisez attentivement le message de rejet, car il précise souvent exactement ce qu’il faut corriger.

91. 

    Règle 2.1 – Informations requises iOS Directive 2.1

    Aucun bug dans le rapport, juste une demande d’information 2.1, répondue par une vidéo de 89 secondes

    Ce qui s'est passé

    Un développeur a soumis sa deuxième application, qui a été rejetée sous la directive 2.1 Information Needed, sans aucun bug signalé. L’équipe de revue demandait une capture d’écran ainsi que des réponses sur le public cible, l’utilisation, les services externes utilisés et les régions visées. Le développeur a enregistré 89 secondes sur le simulateur, allant du lancement à l’utilisation complète de la fonctionnalité principale jusqu’au paywall, a répondu à toutes les questions dans les notes et a resoumis le même jour.

    Résolution

    Enregistrement et réponses envoyés le jour même. Résultat final non communiqué au moment de la publication.

    Leçon

    Pour une nouvelle app, attendez-vous à une demande d'informations 2.1 et préparez-vous. Avant de soumettre, ayez dans les notes de review un court enregistrement du parcours principal et des réponses écrites sur le public, l'usage, les services externes et les régions, pour que la première review ne s'arrête pas sur des questions.

92. 

    Règle 2.5.4 Software Requirements (background modes) iOS Révision sans fin

    Rejeté pour une case restée cochée, le mode audio en arrière-plan, puis dix jours d'attente pour la mise à jour suivante

    Ce qui s'est passé

    Une petite équipe a soumis une mise à jour d'une app déjà en ligne. L'App Review l'a rejetée au titre de la règle 2.5.4 pour un seul paramètre : le mode audio en arrière-plan était activé alors que l'app n'en avait pas besoin. L'équipe a retiré le mode arrière-plan et a soumis à nouveau le jour même, ce qui lui a coûté environ une journée. Sa mise à jour suivante est ensuite restée en review pendant une dizaine de jours.

    Résolution

    Suppression du mode audio en arrière-plan et resoumission le jour même. La mise à jour suivante a attendu environ dix jours en revue.

    Leçon

    Les modes en arrière-plan ne sont autorisés que pour leur usage prévu. Avant chaque soumission, ouvrez la capacité Background Modes et retirez tout ce que l’application n’utilise pas réellement, car une case cochée par erreur suffit pour un rejet, et vous ne pouvez pas prédurer combien de temps durera la prochaine revue.

93. 

    Directive 4.3(a) Spam iOS Directive 4.3

    Une web app dans un wrapper a reçu un spam 4.3(a), le développeur l’a donc reconstruite en app native

    Ce qui s'est passé

    Un développeur a soumis la première version de son application sous forme de web app dans un wrapper natif. App Review l’a rejetée au titre de la directive 4.3(a), la règle anti-spam. Le développeur a reconnu qu’Apple avait raison. Il a reconstruit l’application en véritable app native, déplacé son backend sur un serveur relais qu’il exploite lui-même, et publié le code source code.

    Résolution

    Reconstruite en application native avec un serveur relay auto-hébergé. Le résultat de cette version n'a pas été partagé dans le post.

    Leçon

    Une fine surcouche autour d'un site web est vite perçue comme du spam par l'App Review. Si vous publiez sur l'App Store, donnez à l'app une vraie valeur native dès la première soumission plutôt que d'espérer qu'un site encapsulé passe.

94. 

    Rejet pour contenu inapproprié (captures d'écran, puis sous-titre) iOS Contenu répréhensible Métadonnées et IAP

    Captures d'écran signalées comme inappropriées, puis le sous-titre, pour un jeu sans aucun contenu adulte

    Ce qui s'est passé

    Un petit studio crée des jeux narratifs simples pour iOS, sans thèmes adultes, jeux d'argent ni crypto. Un de leurs jeux, où le joueur incarne une célébrité qui tente de percer à Hollywood, a été rejeté pour contenu inapproprié dans ses captures d'écran. Ces dernières ne montraient que des personnages entièrement habillés. Le studio a remplacé chaque capture et a soumis une nouvelle version. Le rejet suivant concernait un contenu inapproprié dans le sous-titre, qui décrivait simplement le jeu comme un jeu de vie et de drames de célébrités. Chaque review a pris des semaines.

    Résolution

    L’application a été soumise pour la première fois en septembre et n’était toujours pas approuvée fin octobre.

    Leçon

    Lorsque l’App Review signale des métadonnées comme inacceptables sans préciser pourquoi, demandez dans App Store Connect quel élément exact pose problème et pourquoi avant de tout refaire. Examinez les captures d’écran, le sous-titre et les mots-clés ensemble avant de resoumettre, car corriger l’un peut révéler le suivant.

95. 

    Directive 5.2.5 Juridique, Propriété intellectuelle iOS Règle 5 Juridique Métadonnées et IAP

    Refusé au titre de la règle 5.2.5 car les captures d’écran utilisaient un appareil ressemblant à un iPhone

    Ce qui s'est passé

    Un développeur a vu son app rejetée au titre de la règle 5.2.5. App Review a indiqué que les métadonnées contenaient, dans les captures d'écran, des visuels ressemblant à un iPhone, ce qui pouvait prêter à confusion avec les produits Apple. Les appareils présentés n'étaient pas des appareils Apple, seulement des appareils qui y ressemblaient, et le développeur a été surpris car une autre de ses applications avait déjà été approuvée avec le même type de visuels d'appareils.

    Résolution

    Résultat final non communiqué au moment de la publication. Un autre développeur a fait remarquer que l'App Review peut aussi refuser les cadres d'appareil qui ne correspondent pas à la plateforme ou les rendus qui ne ressemblent pas à de vrais iPhones.

    Leçon

    L'approbation d'une app ne crée pas de précédent pour la suivante. Les mockups d'appareil qui ressemblent presque à un iPhone peuvent être considérés comme similaires au point de prêter à confusion avec les produits Apple. Utilisez des captures d'écran simples, ou uniquement les cadres d'appareil qu'Apple fournit pour le marketing, et assurez-vous qu'ils correspondent à la plateforme.

96. 

    Règle 2.1 – Informations requises iOS Directive 2.1

    Première app iOS : demande d'informations 2.1, la solution a été de rendre tout facile à trouver

    Ce qui s'est passé

    Un développeur solo dont la version Android était déjà en ligne sur Google Play a soumis sa première app iOS. Elle comportait trois achats in-app et du contenu généré par les utilisateurs. L'App Review ne l'a pas rejetée d'emblée, mais a envoyé une demande d'information au titre de la directive 2.1. Le développeur a relu la directive 2.1, qui exige que chaque achat in-app soit visible et fonctionnel pour le réviseur, et a aussi vérifié les règles sur le contenu généré par les utilisateurs (1.2) et la suppression de compte (5.1.1(v)). Le lendemain, il a soumis un nouveau build avec une option de signalement et de blocage visible sur chaque contenu utilisateur, des règles communautaires acceptées avant de publier, la déconnexion et le changement de compte, ainsi qu'un enregistrement d'écran montrant où se trouvent les achats, les outils de sécurité et les contrôles de compte.

    Résolution

    Nouveau build soumis le lendemain de la demande. Résultat inconnu au moment de la publication.

    Leçon

    Traitez la revue comme un test d'utilisabilité avec un inconnu pressé par le temps. Chaque achat, option de signalement et de blocage, et contrôle de compte doit être trouvable en quelques secondes, et un enregistrement d'écran dans les notes de revue doit pointer vers chacun d'eux. Être en ligne sur Google Play ne dit rien du passage de l'App Review.

97. 

    Directive 4.3(a) Design, Spam iOS Directive 4.3 Révision sans fin

    Vingt-sept jours dans la file d'attente pour une nouvelle app, puis un rejet pour spam 4.3(a)

    Ce qui s'est passé

    Un développeur a soumis une toute nouvelle application et a attendu 27 jours que l'App Review l'examine. Quand le résultat est enfin apparu dans App Store Connect, il s'agissait d'un rejet selon la directive 4.3(a), Design, Spam. Le développeur a ensuite demandé à d'autres développeurs si quelqu'un avait déjà réussi à surmonter un rejet 4.3(a).

    Résolution

    Aucune solution n'a été partagée au moment de la publication. Le développeur cherchait des conseils auprès de développeurs ayant déjà eu affaire au 4.3(a).

    Leçon

    Une longue attente ne garantit pas que l'application passera. Avec des files d'attente de review aussi lentes, un rejet 4.3(a) après plusieurs semaines coûte un mois entier. Avant de soumettre une nouvelle application, soyez honnête sur ce qui la différencie des applications déjà présentes dans sa catégorie, et précisez-le clairement dans les notes de review et les métadonnées.

98. 

    Directive 4.3(a) Design, Spam machine macOS Directive 4.3

    L'application iPhone était déjà en ligne, puis sa version Mac a été rejetée pour spam

    Ce qui s'est passé

    Un développeur avait déjà une application iPhone en ligne sur l'App Store et avait compilé une version native pour Mac de la même application. La revue App a rejeté l'application Mac en vertu de la directive 4.3(a). Le message indiquait que l'application partageait un binaire, des métadonnées ou un concept similaire avec des applications soumises par d'autres développeurs, avec seulement de légères différences, et suggérait de soumettre une application unique avec un contenu et des fonctionnalités distincts. Le développeur a demandé à la communauté ce qui avait fonctionné pour d'autres confrontés à la directive 4.3.

    Résolution

    Aucune solution n’a été partagée au moment de la publication.

    Leçon

    Chaque plateforme fait l'objet de sa propre revue, et une application iPhone approuvée ne se transfère pas au Mac. Un message 4.3(a) compare votre application à celles d'autres développeurs, donc lorsque vous répondez, expliquez concrètement ce que votre application fait que les applications similaires ne font pas, et pointez les fonctionnalités qui n'existent que dans la vôtre.

99. 

    Révision sans fin iOS Révision sans fin

    Plus de quatorze jours de revue se sont soldés par un refus, et la resoumission a attendu deux semaines de plus

    Ce qui s'est passé

    Un développeur a raconté que son précédent examen avait duré plus de quatorze jours et s'était soldé par un rejet. Il a resoumis le 21 octobre et, presque deux semaines plus tard, la soumission était toujours en « En attente d'examen », alors qu'Apple indique que la plupart des examens prennent 24 à 48 heures.

    Résolution

    Toujours en attente d'examen au moment de la publication.

    Leçon

    Les délais moyens d'examen ne décrivent pas le pire des cas, et un rejet vous renvoie à la fin d'une file d'attente qui avance lentement. Prévoyez vos lancements avec plusieurs semaines de marge et faites en sorte que la première soumission soit aussi complète que possible, pour qu'un rejet ne double pas l'attente.

100. 

     Exigence de suppression de compte (règle 5.1.1(v)) iOS Règle 5.1.1

     Rejeté pour absence de suppression de compte, après que le premier examinateur a supprimé plusieurs comptes

     Ce qui s'est passé

     Un développeur dont l’application reposait sur du contenu public généré par les utilisateurs a été refusé lors de sa deuxième revue, pour absence de suppression de compte. Ses logs montraient que, lors de la première revue, le reviewer avait créé et supprimé plusieurs comptes sans le moindre problème. Le développeur estimait que ce refus tenait davantage à la sévérité de la catégorie qu’à l’absence réelle de la fonctionnalité.

     Résolution

     Aucune solution n’a été partagée au moment de la publication.

     Leçon

     Même quand une fonctionnalité fonctionne, le reviewer doit pouvoir la trouver rapidement. Indiquez le parcours de suppression de compte dans les notes de revue, avec les écrans exacts à toucher, et joignez un court enregistrement d’écran. Pour les applications avec du contenu généré par l’utilisateur, montrez aussi la signalisation, le blocage et la modération, car ces catégories sont examinées de plus près.

101. 

     Règle 2.1(a) : complétude de l’app machine macOS Directive 2.1

     Une app Mac refusée au titre de la règle 2.1(a) pour lecture du keychain de connexion, et les anciens avis de refus ont disparu

     Ce qui s'est passé

     Un développeur a soumis une app Mac et l’App Review l’a rejetée au titre de la directive 2.1(a) car l’app lisait dans le trousseau de connexion. La correction n’a demandé qu’une seule mise à jour. Ce qui a surpris le développeur, c’est App Store Connect lui-même : il n’affiche que les dix dernières soumissions, si bien que les messages de rejet plus anciens disparaissent discrètement de l’historique.

     Résolution

     Corrigé en une mise à jour. Le développeur copie désormais chaque message de rejet dans le commit qui le corrige.

     Leçon

     Ne comptez pas sur App Store Connect comme registre de vos rejets passés, car les soumissions plus anciennes ne sont plus visibles. Conservez le texte intégral du rejet à côté de la correction, dans le commit, le ticket ou vos notes de version, pour garder la formulation exacte si le même problème revient.

102. 

     Directive 1.4.1 Préjudice physique (santé et médical) iOS Révision sans fin

     Dix jours d’examen pour une app santé, puis un rejet 1.4.1 corrigé avec une page de sources en une après-midi

     Ce qui s'est passé

     Un développeur indépendant qui créait une application de santé a attendu plus de dix jours lors de la review App Store. Verdict : un rejet au titre de la règle 1.4.1, qui encadre les applications de santé et médicales. La correction était simple : le développeur a ajouté une page de sources citant l'origine des informations de santé de l'application, et il n'a fallu qu'un après-midi pour la mettre en place.

     Résolution

     Ajout d'une page de sources avec des citations, en un après-midi. Le post ne précise pas si la nouvelle soumission a été approuvée.

     Leçon

     Les applications de santé sont soumises à des exigences plus strictes, et une longue attente peut se solder par une demande que vous auriez pu satisfaire avant de soumettre. Si votre application affiche des informations de santé ou médicales, ajoutez des citations claires dans l'application avant la première soumission. Un développeur a répondu qu'un rappel visible invitant à consulter un médecin est une autre demande courante.

103. 

     Achat in-app trop difficile d'accès pour le reviewer (numéro de règle non précisé) iOS Métadonnées et IAP

     Une mise à jour de jeu refusée car le paywall était trop profond, puis approuvée en 26 heures une fois le déblocage déplacé sur l’écran titre

     Ce qui s'est passé

     Un développeur indépendant a eu besoin de 33 jours et de deux rejets pour faire approuver la version 1.0 de son jeu iOS. La première mise à jour, 1.0.1, a aussi été rejetée, car le paywall était trop enfoui dans le jeu pour que l'évaluateur puisse y accéder. Le développeur a ajouté un bouton de déverrouillage à l'écran titre et a resoumis. Cette fois, le processus complet a pris environ 26 heures, dont seulement 12 minutes réellement en review.

     Résolution

     Ajout d’un bouton de déverrouillage sur l’écran titre. La mise à jour a été validée environ 26 heures après le renvoi.

     Leçon

     Un évaluateur ne jouera pas à votre jeu pendant vingt minutes pour trouver ce que vous vendez. Rendez chaque achat accessible en quelques secondes, ou décrivez le chemin exact dans les notes de review, afin que l'évaluateur puisse le tester sans avoir à chercher.

104. 

     Incohérence de métadonnées d'achat in-app (numéro de règle non précisé) iOS Métadonnées et IAP

     Rejeté car le paywall indiquait 1 mois gratuit alors qu'Apple affichait le tarif annuel

     Ce qui s'est passé

     Un développeur est passé de plusieurs semaines sur TestFlight à un lancement public sur l'App Store, mais a vu un build refusé à cause du paywall. Le paywall indiquait 1 mois gratuit, mais l'écran d'achat Apple affichait la facturation annuelle dès le jour même. Le reviewer n'a pas non plus trouvé l'offre hebdomadaire. Le développeur a corrigé le texte du paywall et la visibilité des offres, soumis un nouveau build, puis a de nouveau attendu la review.

     Résolution

     Le paywall a été corrigé pour que la mention d'essai gratuit corresponde à l'écran d'achat et que l'offre hebdomadaire soit accessible. L'application a ensuite été publiée sur l'App Store.

     Leçon

     Ce que votre paywall promet doit correspondre à ce qu'affiche l'écran d'achat Apple, y compris la durée de l'essai et le début de la facturation. Rendez chaque offre dont le reviewer a besoin pour tester accessible en quelques taps, et vérifiez ce parcours sur une installation fraîche avant de soumettre.

105. 

     Règle 2.1 Exhaustivité de l'app (crash au lancement) iOS Directive 2.1

     Un resoumission avec des correctifs de performance bonus a planté au démarrage et coûté une journée entière

     Ce qui s'est passé

     Après un premier refus de l'App Store qui n'était qu'une demande de précisions, le développeur a décidé d'intégrer des correctifs de performance dans la même nouvelle soumission. Il était si confiant qu'il a même retiré une condition matérielle destinée aux appareils de gamme gaming. L'App Review a rejeté le build à nouveau car il plantait au démarrage, sans log de crash, seulement un message automatisé. Le développeur a supposé un kill mémoire, a remis la condition en place et a passé la journée à réduire les assets, différer les chargements et libérer des ressources sans perdre en performance.

     Résolution

     Il a rétabli la condition matérielle, réduit l'empreinte mémoire et préparé une troisième soumission pour le lendemain. L'issue finale après le troisième tour n'a pas été partagée dans l'article.

     Leçon

     N'empilez pas de correctifs non liés dans une nouvelle soumission destinée à répondre à une question de review. Déployez le changement minimal qui répond au refus, gardez les conditions de stabilité en place pour l'appareil le plus bas que vous prétendez supporter, et testez le démarrage à froid sur cet appareil avant de re-soumettre.

106. 

     Directive 4.3(a) Design Spam iOS Directive 4.3

     Plusieurs petits jeux soumis ensemble ont tous reçu un 4.3(a), puis deux appels ont été annulés

     Ce qui s'est passé

     Un développeur a soumis plusieurs petits jeux à l'App Store à peu près en même temps. Tous ont été rejetés au titre de la règle 4.3(a) pour spam. Après cette vague, il a changé de processus et ne soumet désormais qu'un jeu à la fois. Deux de ces rejets ont ensuite été annulés après un recours auprès de l'App Review Board.

     Résolution

     Passage à une soumission à la fois. Deux des rejets 4.3(a) ont été annulés après recours auprès de l'App Review Board.

     Leçon

     Regrouper des applications similaires dans la même fenêtre de review risque de faire qualifier l'ensemble de spam. Soumettez-les une par une, et si un rejet 4.3(a) vous semble injustifié, faites appel auprès de l'App Review Board en expliquant clairement ce qui distingue chaque application.

107. 

     Règle 1.1 Sécurité, contenu répréhensible (métadonnées de l'app) iOS Contenu répréhensible Métadonnées et IAP

     Une app de rétablissement a été refusée au titre de la règle 1.1 car sa campagne marketing nommait l’habitude qu’elle aide à abandonner

     Ce qui s'est passé

     Une application conçue pour aider les gens à surmonter la pornographie et la luxure a été rejetée au titre de la directive 1.1. App Review a indiqué que le marketing de l'application faisait référence à un contenu répréhensible dans ses métadonnées, y compris la description, les captures d'écran et les mots-clés. Lorsque le développeur a demandé des précisions, App Review a cité un seul mot-clé, porn, a précisé que cette liste n'était pas exhaustive, a averti que l'application ferait l'objet d'un examen complet lors d'une nouvelle soumission, et a déclaré que soumettre à nouveau avec le même marketing, ou en tant que nouvelle application avec le même concept, entraînerait les mêmes violations, voire plus. Le développeur a souligné que des applications similaires déjà présentes sur le store mettent ouvertement en avant l'aide face à la tentation sexuelle.

     Résolution

     Non résolu au moment de la publication. App Review a demandé que toute référence à un contenu répréhensible soit supprimée des métadonnées avant un nouvel examen complet, et le développeur s'est publiquement demandé pourquoi des applications similaires étaient traitées différemment.

     Leçon

     Les applications qui aident à arrêter une pratique « adulte » sont jugées sur les mots de leur propre marketing, pas sur leur intention. Décrivez l'objectif, comme le rétablissement ou la maîtrise de soi, plutôt que de nommer le vice dans les mots-clés, la description et les captures d'écran, et demandez à App Review quels termes exacts ont déclenché le rejet avant de soumettre à nouveau, car la prochaine soumission fera l'objet d'un examen complet.

108. 

     Icône d’app signalée comme inappropriée (numéro de directive non précisé) iOS Contenu répréhensible Métadonnées et IAP

     Une icône d’app déjà approuvée a été rejetée pour exposition excessive

     Ce qui s'est passé

     Une application IA utilisait un personnage illustré comme icône, portant un crop top qui laissait voir une partie de la poitrine et du ventre. Cette même icône avait déjà passé l’App Review. Lors d’une soumission ultérieure, Apple l’a rejetée car la poitrine et le ventre étaient trop exposés. Le développeur a redessiné le personnage avec un haut complet couvrant les deux zones, puis a resoumis l’application.

     Résolution

     L’icône a été redessinée pour que le haut couvre la poitrine et le ventre. Le post ne précise pas la durée de la nouvelle revue.

     Leçon

     Une approbation antérieure ne verrouille pas votre icône ou vos captures d’écran, car chaque soumission peut être réévaluée. Si un personnage de votre art montre de la peau, supposez qu’un examinateur plus strict puisse le signaler, et gardez une variante plus couverte prête à l’emploi pour que la correction soit un simple remplacement, pas une refonte.

109. 

     Flux d'annulation d'abonnement (numéro de directive non précisé) iOS Métadonnées et IAP

     Refusé pour une étape supplémentaire de confirmation à l'annulation, une semaine avant le lancement des messages de rétention par Apple

     Ce qui s'est passé

     Une application d'abonnement affichait son propre écran de confirmation « Êtes-vous sûr ? » lorsque les utilisateurs tentaient de l'annuler. L'App Review a refusé l'application pour cette raison. Moins d'une semaine plus tard, App Store Connect a annoncé les messages de rétention, qui permettent aux développeurs d'afficher un message, avec une image optionnelle ou une offre de rétention, aux abonnés qui tentent d'annuler leur abonnement.

     Résolution

     L'article ne précise pas comment le refus a été résolu. La nouvelle fonctionnalité d'App Store Connect offre désormais une méthode approuvée par Apple pour afficher un message au moment de l'annulation.

     Leçon

     N'ajoutez pas de friction supplémentaire avant l'annulation d'un abonnement. Laissez les utilisateurs accéder directement au flux d'annulation, et si vous souhaitez une dernière chance de les retenir, utilisez les messages et offres de rétention d'Apple plutôt qu'un écran personnalisé.

110. 

     Règles 5.6 Developer Code of Conduct et 2.5.19 Hidden Features iOS Règle 5.6 Code de conduite du développeur Règle 2.5.19 Fonctionnalités cachées

     Refusé au titre de la règle 5.6 pour des fonctionnalités cachées qui s’avéraient être le checkout code intégré à un abonnement SDK

     Ce qui s'est passé

     A solo developer had an iOS goal tracking app rejected seven times on the way to launch. One earlier rejection had been about real money stakes. The last one came under the Developer Code of Conduct: App Review said the app had hidden or misleading functionality and asked for all hidden features to be removed, without saying which one. The app had no remote feature flags, no downloaded code and no special behavior for reviewers. Instead of guessing, the developer scanned their own release binary and found web checkout code from a payment provider that they had never written. It came bundled inside their subscription SDK for that SDK web platform, and the iOS app never used it. Given the earlier money stakes rejection, the developer suspected it looked like a hidden payment path.

     Résolution

     Sans modifier le moindre code, le développeur a répondu à l’App Review avec des faits simples : ce que l’application fait et ne fait pas, l’absence d’enjeux financiers réels, l’origine du code de paiement, la suppression du SDK web code inutilisé et de l’autorisation de bibliothèque photo non utilisée dans le prochain build, et une demande de préciser l’écran signalé. Environ neuf heures plus tard, l’App Review a indiqué qu’elle poursuivait l’examen, et l’application est passée en ligne.

     Leçon

     Sachez tout ce que votre binaire embarque, y compris les code que vos SDKs apportent pour d’autres plateformes, car l’App Review évalue ce qui est dans le build, pas ce que vous appelez. Après un refus 5.6, ne devinez pas et ne resoumettez pas. Répondez calmement avec des détails précis et demandez quel écran ou comportement a été signalé.

111. 

     Directive 2.3.4 Métadonnées exactes (Aperçus d’application) iOS Métadonnées et IAP

     Un aperçu d’application approuvé en octobre a été refusé sous la directive 2.3.4 pour son cadrage un mois plus tard

     Ce qui s'est passé

     Un développeur a soumis une mise à jour de son application iOS et elle a été refusée sous la directive 2.3.4. L’App Review a indiqué que la vidéo d’aperçu d’application contenait un cadre autour de la capture d’écran. La même vidéo avait été approuvée le mois précédent. Le développeur a souligné que d’autres applications sur le store, y compris une très connue dont l’aperçu montre une personne plutôt que l’application, utilisent des aperçus d’application avec peu ou pas de captures de l’application elle-même.

     Résolution

     Le développeur a supprimé la vidéo App Preview et a resoumis la mise à jour. L’article ne précise pas comment s’est passée la nouvelle revue.

     Leçon

     Une App Preview approuvée une fois peut être rejetée lors d’une mise à jour ultérieure, car chaque soumission est revue. Limitez les aperçus à des captures d’écran simples de l’application, sans cadre décoratif. Si l’une est signalée, la supprimer est le moyen le plus rapide de débloquer la mise à jour pendant que vous la retravaillez.

112. 

     Section 3.2(f) (contrat de licence du programme Apple Developer) machine macOS Résiliation de compte Révision sans fin

     Une mise à jour macOS corrigeant un problème d’icône est restée en revue pendant environ 45 jours, avant qu’un avis 3.2(f) n’arrive

     Ce qui s'est passé

     Un développeur indépendant avait une application macOS signalée par App Review pour des raisons de marque. Le 15 septembre 2026, il a soumis une mise à jour tenant compte des retours, y compris une icône entièrement redessinée. La mise à jour est restée « En revue » pendant environ 45 jours sans décision, et le développeur a envoyé deux demandes de revue accélérée via les canaux officiels. Le 30 octobre 2026, alors que cette mise à jour corrigée était toujours en attente, un avis de résiliation imminente du compte développeur est arrivé au titre de la section 3.2(f).

     Résolution

     Appel en cours au moment de la publication. Le développeur a déposé un appel formel et contacté le support développeurs séparément, sans avoir reçu de réponse substantielle.

     Leçon

     Une correction en attente dans la file d’attente ne suspend pas l’application des règles aux soumissions antérieures. Conservez un journal daté de chaque rejet, de chaque modification effectuée en réponse et de chaque demande d’accélération, afin que l’appel puisse démontrer précisément ce que vous avez corrigé et quand.

Cette page ne constitue pas un conseil juridique et ne prédit pas ce qu'Apple fera lors de votre prochaine soumission.