Guideline 2.3.10 : application refusée pour ses métadonnées

La guideline 2.3.10, « Accurate Metadata », refuse une app dont la fiche ou l'interface parle d'une autre plateforme : Android, Google Play, un téléphone d'une autre marque dans une capture. Ta fiche parle de ton app sur les appareils Apple, et de rien d'autre. Si la mention est dans la fiche, tu la corriges et tu renvoies le même build. Si elle est dans l'app, il faut un nouveau build.

Deux cousines tombent pour la même raison : la 2.3.3, quand les captures ne montrent pas l'app en usage, et la 2.3.7, quand le nom, le sous-titre ou les mots-clés trompent. Je prépare moi‑même les fiches et les captures de mes apps : Solys, TradaZen et Nolera sont sur l'App Store. Ce guide s'appuie sur le texte officiel d'Apple, lu le 15 octobre 2026. Les achats intégrés dans la fiche relèvent de la 2.3.2, que je traite à part. Pour la vue d'ensemble des refus, lis pourquoi Apple refuse une app.

Que dit la guideline 2.3.10 ?

La section 2.3 des App Review Guidelines part d'une idée simple : la personne qui télécharge doit savoir ce qu'elle obtient. Description, captures, aperçus et informations de confidentialité doivent refléter l'expérience réelle de l'app.

La 2.3.10 précise : « don't include names, icons, or imagery of other mobile platforms or alternative app marketplaces in your app or metadata, unless there is specific, approved interactive functionality. » En clair : pas de nom, d'icône ni d'image d'une autre plateforme mobile ou d'une boutique d'apps alternative, ni dans l'app, ni dans sa fiche. Elle ajoute : « Make sure your app metadata is focused on the app itself and its experience. » La fiche parle de l'app, sans information hors sujet.

Trois points à retenir :

• L'app compte autant que la fiche. Un bouton « Disponible sur Google Play » dans l'app tombe sous la même règle.
• Les boutiques alternatives sont visées aussi. Celles qui existent dans certains pays ne se citent pas plus qu'Android.
• L'exception est étroite. Une app peut nommer une autre plateforme si une fonction interactive précise, approuvée par Apple, le justifie. Exemple : une app de transfert de fichiers entre un iPhone et un téléphone Android peut citer Android, puisque c'est sa fonction. Explique-le dans les notes de revue.

Le message type d'un refus 2.3.10

L'intitulé est « Guideline 2.3.10 - Performance - Accurate Metadata ». Dans un message publié sur les forums d'Apple, Apple écrit : « Referencing third-party platforms in your app or its metadata is not permitted on the App Store unless there is specific interactive functionality. » La suite demande de retirer toute mention de l'app et de sa fiche : description, texte promotionnel, nouveautés, aperçus et captures. Dans ce cas, les captures venaient de pages du site du développeur, et Apple y relevait un appareil et une barre d'état qui n'étaient pas ceux d'un iPhone.

La page d'aide d'Apple sur les captures en usage le confirme : une capture qui fait référence à une autre plateforme, par exemple dans sa barre d'état, est jugée au titre de la 2.3.10.

Où se cachent les mentions qui font tomber la 2.3.10

• La description et le texte promotionnel. « Aussi disponible sur Android » est la phrase la plus courante.
• Les notes de version. C'est le piège des projets publiés sur les deux stores. Une note commune comme « Correction du clavier sur Android » finit sur l'App Store. Si tu prépares les deux versions avec un seul projet, comme dans app iOS ou Android, écris des notes séparées.
• Les captures et les aperçus. Un cadre de téléphone Android, une barre d'état Android, une capture prise sur l'émulateur Android ou sur ton site web.
• L'app elle‑même. Un écran de partage ou de parrainage avec les deux badges de store, un lien « Noter l'app » qui ouvre le Play Store, un texte d'accueil qui parle d'Android. Dans un projet React Native ou Expo, choisis le lien et le badge selon Platform.OS : la version iOS n'affiche alors que l'App Store.
• Chaque langue. Chaque localisation a ses propres textes et ses propres captures, et Apple juge les captures de chaque localisation. Une mention oubliée dans une seule langue peut suffire à faire refuser la soumission.

Pour chercher, je lance une recherche sur les textes de la fiche et les fichiers de traduction de l'app : rg -i "android|google play|play store". Puis je regarde chaque capture, langue par langue, en cherchant une barre d'état ou un cadre qui ne vient pas d'un iPhone.

2.3.3 : des captures qui montrent l'app en usage

Le texte officiel : « Screenshots should show the app in use, and not merely the title art, login page, or splash screen. » Les captures doivent montrer l'app en train de servir, pas seulement le logo, l'écran de connexion ou l'écran de lancement. Les textes et images ajoutés par-dessus sont permis.

La page d'aide d'Apple donne une règle chiffrée. Pour chaque type d'appareil, plus de la moitié des captures doivent montrer l'app en usage. Avec trois captures, deux doivent le faire. Avec quatre, trois. Les autres peuvent présenter les bénéfices avec des visuels marketing. Sur les captures en usage, les textes ajoutés ne doivent pas cacher l'interface.

C'est compatible avec une fiche qui vend : un titre court au-dessus d'un vrai écran reste une capture en usage. Les tailles et le nombre de captures, jusqu'à dix par taille d'appareil, sont dans les spécifications des captures.

2.3.7 : un nom, un sous-titre et des mots-clés honnêtes

La 2.3.7 demande un nom unique et des mots-clés qui décrivent l'app, sans bourrer les métadonnées de « trademarked terms, popular app names, pricing information, or other irrelevant phrases just to game the system ». Pas de marques déposées, de noms d'apps connues, de prix ni de phrases hors sujet pour tromper la recherche.

Ce qu'elle impose en pratique :

• Le nom tient en 30 caractères. Le sous-titre aussi, selon les informations de l'app d'App Store Connect.
• Le sous-titre ne cite pas d'autres apps et ne promet rien d'invérifiable.
• Le nom, le sous-titre, les captures et les aperçus n'affichent pas de prix.
• Les mots-clés ne contiennent ni nom d'app ni nom d'entreprise tiers. L'aide sur les informations de version l'écrit : « Names of other apps or companies aren't allowed. »

Le mot « gratuit » est un piège. Dans un refus 2.3.7 publié sur les forums d'Apple, Apple précise que les mentions de services gratuits ou en promotion comptent comme une référence de prix.

Dire qu'une fonction demande un abonnement est attendu, afficher son prix sur une capture ne l'est pas. La première exigence vient de la 2.3.2, la seconde de la 2.3.7. Apple résume ses conseils de nom, de sous-titre et de mots-clés sur sa page consacrée à la fiche produit. La méthode pour choisir tes mots est dans mots-clés App Store, et la fiche complète sur la page ASO App Store.

Refusé ou accepté : le tableau règle par règle

Les versions refusées sont des exemples construits. La ligne du nom accepté est le nom réel de Solys sur l'App Store français, en octobre 2026.

Règle	Refusé (exemple)	Accepté
2.3.10	« Disponible sur iPhone et Android »	« Disponible sur iPhone et iPad »
2.3.10	Note « Bug corrigé sur Android »	« Correction de l'affichage du clavier »
2.3.10	Capture dans un cadre de téléphone Android	Capture du simulateur iPhone
2.3.10	Badges App Store et Google Play dans l'app	Badge App Store seul sur iPhone
2.3.3	Logo, connexion, lancement, puis 2 écrans	3 écrans d'usage sur 5, au moins
2.3.3	Texte marketing plein écran, sans app	Titre court au-dessus d'un vrai écran
2.3.3	Maquette d'une fonction pas encore livrée	Écran réel de la version soumise
2.3.7	Nom « Réveil Alarme Sommeil Pro Gratuit »	« Solys : Limiter temps d'écran »
2.3.7	Sous-titre « Mieux que [app concurrente] »	Sous-titre qui dit le bénéfice
2.3.7	Mots-clés avec des noms d'apps rivales	Mots d'usage : réveil, matin, routine
2.3.7	« Gratuit » ou « -50 % » sur une capture	Aucun prix ni promotion sur les captures

Un cas vécu, hors 2.3.10 : un nom tiers dans la description

Sur Nolera, mon app de dressing, la description nommait OpenAI, le service d'IA utilisé pour l'essayage. Apple a refusé la soumission en citant la section 5, « Legal », au sujet de la disponibilité en Chine. La solution retenue a été de retirer la Chine des pays où l'app est proposée.

Ce n'était pas un refus 2.3.10, mais il vient du même endroit : un nom de service tiers dans la fiche n'est jamais neutre. Avant d'en écrire un, demande-toi s'il aide la personne à choisir ton app. Le plus souvent, décrire ce que fait la fonction suffit.

Corriger et renvoyer

1. Lis la liste d'Apple. Le message dit où il a vu la mention : description, captures, app. Ajoute ta propre recherche, langue par langue.
2. Corrige tout, pas seulement l'exemple cité. Une deuxième mention trouvée au tour suivant coûte un cycle de revue entier.
3. Fiche seule : même build. Tu modifies dans App Store Connect, tu réponds à App Review et tu renvoies. Le détail est dans délai de validation App Store.
4. Mention dans l'app : nouveau build. Le reviewer teste le binaire envoyé.
5. Vraie fonction interactive : explique-la. Dis dans ta réponse ce que l'app fait avec l'autre plateforme, et où le tester.

Le modèle de réponse que j'utiliserais, en anglais, à adapter :

Hello,

Thank you for your review.

We removed every reference to other platforms:
- Description and promotional text: [what changed].
- What's New: [what changed].
- Screenshots: replaced with captures from iPhone,
  in all [number] localizations.

No change was needed in the app binary.

Best regards,

N'écris la dernière ligne que si elle est vraie.

La checklist 2.3 avant soumission

• Aucun mot « Android », « Google Play » ou « Play Store » dans la fiche, dans aucune langue.
• Notes de version écrites pour iOS, pas copiées de la version Android.
• Captures prises sur iPhone ou iPad, sans cadre ni barre d'état d'une autre marque.
• Plus de la moitié des captures de chaque appareil montrent l'app en usage.
• Aucune maquette d'une fonction absente de la version soumise.
• Nom et sous-titre sans prix, sans nom d'app concurrente, sans promesse invérifiable.
• Mots-clés sans marque tierce ni nom d'entreprise.
• Aucun « gratuit » ni pourcentage de réduction sur les captures.
• Dans l'app, liens et badges de store adaptés à la plateforme.

Une fiche qui passe la revue du premier coup

Le Kit Review Apple réunit ma checklist avant l'envoi et des skills Claude Code qui relisent ton projet, ton paywall et ta fiche. Pour des captures qui vendent sans enfreindre la 2.3.3, le Kit Captures crée tes visuels à partir des vrais écrans de ton app, aux tailles demandées par Apple. Pour un regard humain, réserve une heure avec moi. La démarche complète après un refus est sur la page application refusée par Apple.

Si tu prépares ta première sortie, fais ton diagnostic gratuit : il remet les étapes dans l'ordre et t'envoie ma checklist anti-refus Apple. L'accueil montre comment créer une application mobile en pensant à la fiche dès le départ.

Questions fréquentes

Que veut dire « Guideline 2.3.10 - Performance - Accurate Metadata » ?

C'est l'intitulé du refus pour mention d'une autre plateforme. Apple a trouvé, dans ta fiche ou dans ton app, un nom, une icône ou une image d'Android, de Google Play ou d'une autre boutique d'apps. La correction : retirer chaque mention, dans chaque langue.

Peut-on écrire que son application existe aussi sur Android ?

Pas dans la fiche ni dans la version iOS de l'app. La seule exception est une fonction interactive réelle avec l'autre plateforme, à expliquer dans les notes de revue. Pour dire que ton app existe ailleurs, utilise ton site web.

Combien de captures doivent montrer l'application en usage ?

Plus de la moitié, pour chaque type d'appareil. Avec trois captures, deux montrent l'app en usage. Avec quatre, trois. Les autres peuvent présenter tes bénéfices avec des visuels marketing.

Faut-il un nouveau build après un refus 2.3.10 ?

Pas si la mention est seulement dans la fiche : tu corriges dans App Store Connect et tu renvoies le même build. Si la mention est dans l'app, comme un badge Google Play sur un écran de partage, il faut un nouveau build.

Peut-on citer une app concurrente dans ses mots-clés ?

Non. L'aide d'App Store Connect interdit les noms d'autres apps et d'entreprises dans les mots-clés, et la 2.3.7 refuse les marques déposées utilisées pour tromper la recherche. Mise plutôt sur les mots que ton public tape pour décrire son besoin.