Refus Apple : pourquoi ton app est refusée (5 cas réels)

Un refus Apple arrive presque toujours pour une raison précise, écrite dans le message de la revue : une guideline numérotée, souvent accompagnée d'une capture. Les motifs les plus fréquents pour une première app sont une app qui ne se termine pas (2.1), une confidentialité mal déclarée (5.1.1), des métadonnées trompeuses (2.3.2), un paiement qui contourne l'achat intégré (3.1.1) ou une demande de note mal placée (5.6.3). Dans la grande majorité des cas, le reviewer a bien compris ton app : c'est ta soumission qui était attaquable.

Je le sais parce que j'ai pris ces refus moi‑même. Je publie mes propres apps iOS : Solys (un réveil à mini-jeux) et TradaZen (un simulateur de trading) sont sur l'App Store. Solys a pris deux refus, l'un avant sa sortie, l'autre sur une mise à jour, et deux autres apps, Clic et Nolera, ont été refusées, corrigées puis renvoyées à Apple. Voici les cinq refus, leur vraie cause, puis la méthode pour répondre et la checklist que j'applique avant chaque envoi.

Pourquoi Apple refuse une app : les 5 refus que j'ai pris

Refus 2.1 sur Solys : la démo était impossible à gagner

L'onboarding de Solys propose une démo jouable : il faut gagner un mini-jeu, comme au réveil. Sur mes téléphones, tout marchait. Le reviewer, lui, testait sur un iPad, où une app iPhone tourne en mode compatibilité dans une fenêtre plus petite. À cette taille, le passage laissé à l'oiseau du mini-jeu devenait plus étroit que l'oiseau lui‑même, et le bouton « Continuer » ne s'allumait qu'en cas de victoire. Apple a demandé de fournir un moyen de passer la mission de jeu.

Le correctif : une démo dont la géométrie se calcule à partir de la taille réelle de l'écran, et un lien pour passer la démo en cas d'échec.

La leçon : toute étape obligatoire doit avoir une sortie, et chaque écran obligatoire se teste sur le plus petit format possible avant chaque envoi.

Refus 5.6.3 sur Solys : la demande de note pendant l'onboarding

Deuxième refus, sur la mise à jour suivante. Apple a écrit que l'app demandait une note au premier lancement ou pendant l'onboarding. L'écran de note arrivait juste après la démo, avant que l'utilisateur ait vécu quoi que ce soit dans l'app.

Le correctif : la demande a été déplacée en fin de parcours, et elle ne s'affiche que si l'utilisateur vient de gagner la démo.

La leçon : chaque demande sensible (note, notification, abonnement, suivi) arrive après une preuve de valeur, jamais avant.

Refus 5.1.1 sur Clic : la politique de confidentialité en ligne n'était pas à jour

Clic génère du contenu avec l'IA, et l'app contenait bien son écran de consentement. Le problème était ailleurs : la politique de confidentialité publiée sur le site était l'ancienne version, et elle ne décrivait pas tout ce que l'app collecte.

Le correctif : politique complète publiée, résumé en anglais ajouté, notes de revue mises à jour.

La leçon : Apple lit ta politique en ligne, pas celle qui dort dans ton dépôt. Avant chaque envoi, ouvre l'URL déclarée et vérifie qu'elle dit ce que ton app fait.

Refus 5.1.1 sur Nolera : un bouton « Autoriser » avant la demande du système

Avant la vraie demande d'accès à la caméra d'iOS, Nolera affichait un écran explicatif avec un bouton « Autoriser ». Pour Apple, ce libellé pousse à accepter avant la demande officielle du système.

Le correctif : le bouton s'appelle désormais « Continuer », dans les 8 langues de l'app.

La leçon : un écran qui prépare une permission explique, il ne décide pas à la place de l'utilisateur. Les recommandations d'Apple sont dans ses règles de design sur la confidentialité.

Refus 2.3.2 sur Nolera : l'icône réutilisée comme image promotionnelle

Les abonnements peuvent avoir une image promotionnelle dans App Store Connect. Sur deux abonnements de Nolera, c'était simplement l'icône de l'app. Apple l'a jugé non conforme.

Le correctif : les images ont été retirées des deux abonnements, et la soumission a été recréée.

La leçon : chaque élément de ta fiche est examiné, y compris ceux que tu remplis sans y penser, comme la classification par âge.

Quelles sont les guidelines qui tombent le plus souvent ?

Toutes les règles sont dans les App Review Guidelines. Celles qui piègent le plus souvent une première app :

2.1 : App Completeness. L'app plante, un bouton mène nulle part, un écran obligatoire ne passe pas sur un format. Si ton app demande une connexion, fournis un compte de démonstration dans les notes de revue, sinon le reviewer reste bloqué à l'écran de connexion. Tout ce qu'il faut savoir sur ce motif est dans mon guide de la guideline 2.1.

2.3 : Metadata. Captures qui ne montrent pas l'app réelle, description qui promet une fonction absente, images promotionnelles non conformes.

3.1.1 : In-App Purchase. Pour débloquer du contenu ou des fonctions numériques dans l'app, la règle générale est l'achat intégré d'Apple. Les exceptions dépendent des pays et évoluent : lis la version à jour des guidelines avant de prévoir un autre moyen de paiement. Le chantier complet est sur la page abonnements in-app iOS.

3.1.2 : Subscriptions. Une app à abonnement doit présenter clairement ce que l'utilisateur obtient et à quel prix. Les erreurs classiques d'écran de paiement sont dans paywall iOS : 7 erreurs de débutant.

4.3 : Spam. L'app ressemble à mille autres ou n'apporte pas assez par elle‑même. C'est le refus le plus dur à corriger : il se prévient dès le choix de l'idée. Je l'explique en détail dans le guide de la guideline 4.3.

5.1.1 : Privacy. Déclarations de collecte qui ne correspondent pas au comportement de l'app, politique de confidentialité incomplète, permission demandée sans explication claire.

Comment répondre à un refus Apple sans perdre de jours ?

Un refus n'est pas un verdict, c'est un aller-retour. La procédure qui marche :

1. Lis le motif deux fois. Le message cite la guideline et joint souvent une capture. Beaucoup de développeurs répondent à côté parce qu'ils ont lu trop vite.
2. Cherche la vraie cause. Sur Clic comme sur Nolera, la cause réelle n'était pas celle que le texte laissait croire au premier abord. Reproduis le problème dans les conditions du reviewer : même type d'appareil, compte neuf, premier lancement.
3. Corrige le motif, pas autre chose. Ce n'est pas le moment d'ajouter trois fonctions : chaque changement agrandit la surface de revue.
4. Réponds dans App Store Connect. Explique en deux phrases factuelles ce que tu as corrigé, en répondant au message d'App Review.
5. Fais appel seulement si tu es sûr. Apple permet de saisir l'App Review Board si tu penses que ton app a été mal comprise, avec un seul appel par soumission refusée. Contester un refus mérité fait perdre du temps pour rien.

Côté délai, Apple indique examiner au moins 50 % des soumissions en moins de 24 heures, et 90 % en moins de 48 heures. Ce sont les refus qui allongent le calendrier, pas la file d'attente : le détail est dans délai de validation App Store. La démarche complète après un refus est sur la page application refusée par Apple.

Un refus évitable coûte un cycle de revue complet. La meilleure réponse à Apple, c'est la soumission qui ne lui laisse rien à reprocher.

La checklist que j'applique avant chaque envoi

Construite refus après refus, sur mes apps :

• Chaque écran obligatoire testé sur le plus petit iPhone, le plus grand, et sur iPad en mode compatibilité, selon la grille de la guideline 4.0 design
• Une sortie possible sur chaque étape de l'onboarding, même en cas d'échec
• Compte de démonstration dans les notes de revue si l'app a une connexion
• Achats testés en sandbox, restauration comprise
• Prix, durée et liens vers les conditions et la confidentialité présents là où Apple les exige, dans chaque langue
• Politique de confidentialité en ligne relue le jour de l'envoi
• Déclarations de confidentialité alignées sur ce que l'app collecte réellement, privacy manifest compris
• Écrans avant permission sans bouton « Autoriser »
• Demandes de note et de notification placées après une preuve de valeur, sans rien débloquer contre une note (guideline 3.2.2)
• Images promotionnelles et captures qui montrent l'app réelle, y compris sur tes pages produit personnalisées

Si c'est ta première publication, la page publier une application sur l'App Store reprend toutes les étapes avant l'envoi.

Un modèle pour expliquer ton parcours à App Review

Télécharge le modèle de notes App Review : consignes en français, notes en anglais à compléter et trame de réponse à un refus. Il te fait préciser la version, le chemin dans les écrans et le résultat attendu. Ne conserve que ce qui existe dans ta build.

Remplace « l’app sauvegarde correctement » par un scénario reproductible : écran de départ, action, fermeture et relance, résultat retrouvé. Après un refus, cite le comportement corrigé et l’appareil sur lequel tu l’as vérifié. Si tu n’as pas reproduit le problème, explique ce qui manque pour le reproduire.

Les identifiants d’un compte de démonstration se renseignent dans les champs dédiés d’App Store Connect, jamais dans un fichier public. Tu peux préparer les preuves avec la grille de tests TestFlight et retrouver les cinq modèles gratuits.

Éviter ces refus avant l'envoi

Le Kit Review Apple réunit ma checklist avant l'envoi, mes refus d'Apple corrigés et des skills Claude Code qui relisent ton projet, ton paywall et ta fiche avant l'envoi.

Ton app est déjà refusée ? Le kit t'aide à retrouver la règle citée, ce qu'elle demande, et un exemple de correction et de réponse. Si tu veux qu'on regarde ton dossier ensemble dès maintenant, réserve une heure avec moi, en visio.

Personne ne peut garantir qu'Apple acceptera ton app. Partir de refus déjà vécus réduit simplement les chances de te faire prendre par les mêmes.

Tu n'as pas encore envoyé ton app ? Le diagnostic gratuit t'envoie ma checklist anti-refus Apple et te dit ce qui reste à faire. Si tu en es encore à la construire, l'accueil montre comment créer une application mobile en gardant ces refus en tête.

Questions fréquentes

Pourquoi mon application est-elle refusée par Apple ?

Presque toujours pour une raison précise, écrite dans le message de la revue : une guideline numérotée, souvent accompagnée d'une capture. Pour une première app, les motifs les plus fréquents sont une app qui ne se termine pas (2.1), une confidentialité mal déclarée (5.1.1) et des métadonnées trompeuses (2.3.2). Il y a aussi un paiement qui contourne l'achat intégré (3.1.1) et une demande de note mal placée (5.6.3).

Pourquoi mon app est-elle refusée alors qu'elle fonctionne sur mon iPhone ?

Parce que le reviewer peut tester dans d'autres conditions que les tiennes. Sur Solys, mon réveil à mini-jeux, il testait sur un iPad, où une app iPhone tourne en mode compatibilité dans une fenêtre plus petite. La démo y était impossible à gagner. Le correctif : une démo calculée sur la taille réelle de l'écran, et un lien pour la passer en cas d'échec.

Que faire quand Apple refuse mon application ?

Lis le motif deux fois, puis cherche la vraie cause en reproduisant le problème dans les conditions du reviewer : même type d'appareil, compte neuf, premier lancement. Corrige le motif et rien d'autre, car chaque changement agrandit la surface de revue. Réponds ensuite dans App Store Connect, en deux phrases factuelles sur ce que tu as corrigé.

Peut-on contester un refus d'Apple ?

Oui, mais seulement si tu es sûr de ton fait. Apple permet de saisir l'App Review Board si tu penses que ton app a été mal comprise, avec un seul appel par soumission refusée. Contester un refus mérité fait perdre du temps pour rien. Sinon, corrige le motif et réponds dans App Store Connect.

Un refus rallonge-t-il le délai de publication ?

Oui. Apple indique examiner au moins 50 % des soumissions en moins de 24 heures, et 90 % en moins de 48 heures : ce sont donc les refus qui allongent le calendrier, pas la file d'attente. Un refus évitable coûte un cycle de revue complet. Le détail des délais est dans délai de validation App Store.

Que vérifier avant d'envoyer une app à Apple ?

Teste chaque écran obligatoire sur le plus petit iPhone, le plus grand et un iPad en mode compatibilité, puis teste les achats en sandbox, restauration comprise. Relis ta politique de confidentialité en ligne le jour de l'envoi et fournis un compte de démonstration dans les notes de revue si l'app a une connexion. Cette checklist s'est construite refus après refus, sur mes apps.