Guideline 4.3 Design Spam : application refusée, que faire ?

Guideline 4.3 Design Spam : la réponse courte

La guideline 4.3 est la règle anti-spam de l'App Store. La 4.3(a) interdit de publier plusieurs fois la même application, et sert en pratique contre les applications reconditionnées. La 4.3(b) refuse les apps impossibles à distinguer de l'existant, surtout dans les catégories saturées. Le remède est de fond : une fonction principale que personne d'autre n'offre.

C'est le refus le plus dur à corriger : il remet en cause la raison d'être de ton app, et aucun correctif de code ne suffit si le produit ressemble trop à l'existant.

Je publie mes propres apps iOS : Solys, un réveil à mini-jeux, et TradaZen, un entraînement au trading, sont sur l'App Store. Nolera et Clic ont été refusées puis corrigées. J'ai pris des refus 2.1, 5.6.3 et 2.3.2, que je détaille dans pourquoi Apple refuse ton app. Je n'ai jamais pris de refus 4.3, et je ne vais pas te raconter le contraire. Ce guide s'appuie sur le texte officiel d'Apple, paraphrasé en français.

Que dit exactement la guideline 4.3 ?

La 4.3, « Spam », se trouve dans la section 4, « Design », des App Review Guidelines. Ses deux parties visent deux problèmes différents.

4.3(a) : une seule application, pas une copie par variante

Le texte officiel demande de ne pas créer plusieurs Bundle IDs pour la même app. L'exemple d'Apple : publier une app de carte par ville du monde, au lieu d'une seule carte mondiale où l'on cherche sa ville. Si ton app a des versions par lieu, par équipe sportive ou par université, Apple te conseille de soumettre une seule app et de proposer les variantes par achat intégré.

En pratique, le message de refus va plus loin que cet exemple. Dans les refus 4.3(a) que des développeurs ont publiés sur les forums développeurs d'Apple, Apple écrit que l'app partage « a similar binary, metadata, and/or concept » avec des apps soumises par d'autres développeurs, avec seulement des différences mineures. Le message qualifie ces apps similaires ou reconditionnées de spam. Trois mots comptent : le binaire (le code compilé), les métadonnées (nom, description, captures) et le concept.

Deux autres règles vont dans le même sens. La 4.2.6, une sous-règle de la guideline 4.2, refuse les apps créées à partir d'un modèle commercial ou d'un service de génération d'apps, sauf si elles sont soumises directement par le fournisseur du contenu. La guideline 4.1, « Copycats », interdit de copier une app populaire en changeant un peu son nom ou son interface. Elle commence par une phrase simple : « Come up with your own ideas. »

4.3(b) : les catégories saturées

La 4.3(b) refuse les apps impossibles à distinguer de ce qui est déjà largement disponible : pour Apple, ces variantes opportunistes dégradent la découverte sur l'App Store.

Le texte nomme les catégories concernées. Les apps de rencontre, de lampe torche, d'effets sonores, de fonds d'écran, de minuteurs simples et de voyance (« fortune telling ») sont déjà bien établies. Apple n'accepte plus de nouvelles soumissions dans ces catégories, sauf si elles offrent « a meaningfully different or improved experience ». Apple peut même retirer celles qui ne sont ni mises à jour ni améliorées, ou qui n'attirent personne.

Une seconde liste est plus sévère : jeux à boire, Kama Sutra, apps de pets et de rots. Apple les juge médiocres ou de faible effort, et des soumissions répétées de ce type peuvent mener à l'exclusion du programme développeur.

Les horoscopes et l'astrologie ne sont pas nommés tels quels dans la version actuelle du texte. Une app d'horoscope quotidien générique reste très proche de la voyance, et je la traiterais comme une catégorie saturée.

Pourquoi la 4.3 tombe plus souvent avec l'IA et les templates

Les templates partagent tout par construction

Un modèle d'app vendu en ligne est acheté par de nombreux développeurs, qui changent les couleurs, l'icône et le nom, puis soumettent. Apple ne détaille pas comment il repère les ressemblances, mais son message parle du binaire, des métadonnées et du concept : trois choses qu'un template partage avec toutes ses copies. C'est exactement le cas que visent la 4.3(a) et la 4.2.6.

L'IA produit la version moyenne de ton idée

Demande à une IA « une app de suivi d'habitudes » : elle te rend la version la plus probable de l'idée, donc la moyenne de l'existant, avec les mêmes écrans et le même onboarding. Le code est peut-être original, le concept ne l'est pas. Or la 4.3(b) juge l'expérience, pas l'originalité du code.

L'IA code très bien une idée différenciée, mais ne trouve pas la différence à ta place. Je détaille ce qu'elle fait bien et ce qu'elle rate dans créer une app iOS avec l'IA.

Comment différencier réellement ton application

Une fonction principale que personne n'offre exactement ainsi

C'est la règle que je m'impose sur chaque idée, justement pour éviter la 4.3 : une fonction principale que personne d'autre n'offre exactement ainsi. Un réveil de plus serait attaquable, les minuteurs simples font partie des catégories citées par Apple. Solys est un réveil qui t'oblige à gagner un mini-jeu pour l'arrêter. La différence tient en une phrase, et elle se voit dès la première utilisation.

Le test : complète « c'est la seule app qui... ». Si tu ne peux finir qu'avec « mais en plus joli », ta différence est trop faible.

Du contenu et une logique qui t'appartiennent

Un habillage différent ne suffit pas. Ce qui distingue une app, c'est ce qu'elle produit : contenus écrits pour elle, données qu'elle calcule, mécanique introuvable ailleurs. Si tu pars d'un template ou d'un projet open source, change la logique, pas seulement les couleurs.

Un nom, des captures et une description qui le prouvent

Le message 4.3(a) cite les métadonnées : le reviewer juge aussi ta fiche, comme pour la guideline 2.3.10. Un nom générique du type « Lampe Torche Pro » annonce une copie avant même l'ouverture de l'app. Ton nom et ton sous-titre doivent dire la fonction unique, ta première capture doit la montrer, et ta description doit s'ouvrir sur elle. Ce travail sert aussi ton référencement : la méthode est sur la page ASO App Store.

Une seule application pour toutes tes variantes

Si ton idée se décline par ville, par équipe ou par thème, publie une seule app avec un choix à l'intérieur, et des achats intégrés si les variantes sont payantes. C'est la lecture littérale de la 4.3(a).

Comment répondre à un refus 4.3 dans App Store Connect

Ce qu'on appelait le Resolution Center se trouve aujourd'hui dans la section App Review d'App Store Connect. Tu y réponds au message d'App Review avec du texte et des pièces jointes, captures ou documents, tant que tu n'as pas soumis à nouveau.

1. Identifie la sous-règle. Un refus 4.3(a) parle de ressemblance avec d'autres apps ou de variantes multiples. Un refus 4.3(b) parle d'une catégorie saturée.
2. Sois honnête sur le fond. Si ton app vient d'un template ou ressemble vraiment à l'existant, ne discute pas : change le produit, pas la formulation.
3. Si ta différence est réelle, montre-la. Réponds court, factuel, en anglais, avec une vidéo de la fonction principale en pièce jointe.

Le modèle que j'utiliserais, à adapter :

Hello App Review team,

Thank you for your feedback regarding Guideline 4.3.

[App name] is not a variant of an existing app. Its core feature is:
[one sentence: what the user can do that no other app offers this way].

What makes it different:
- [Unique feature, and where to find it in the app]
- [Original content or logic created for this app]
- [Why it matters to the user]

All code, content and assets were created for this app.
We do not publish any other app based on the same code or concept.

Attached: a short screen recording of the core feature.

If a specific part of the app looks similar to existing apps,
could you tell us which one, so we can address it precisely?

Best regards,
[Your name]

N'écris les deux phrases sur le code et les autres apps que si elles sont vraies. Une affirmation fausse dans une réponse à Apple te coûtera plus cher qu'un refus. La démarche complète après n'importe quel refus est sur la page application refusée par Apple.

Quand faire appel auprès de l'App Review Board

Apple permet de faire appel auprès de l'App Review Board si tu penses que le reviewer a mal compris le concept et le fonctionnement de ton app, ou que tu as été traité injustement pendant la revue. Apple pose trois conditions : donner des raisons précises pour lesquelles ton app respecte les guidelines, ne déposer qu'un seul appel par soumission refusée, et répondre d'abord à toute demande d'information complémentaire.

Fais appel quand ta différence est réelle, visible dans l'app, et que ta réponse dans App Store Connect n'a pas suffi à la faire comprendre. Pour un template, un clone ou une variante sans différence, l'appel ne changera pas le produit.

Apple propose aussi, sur la même page, des rendez-vous vidéo de 30 minutes avec App Review. Si ton idée frôle une catégorie saturée, pose la question avant de construire.

La checklist anti-4.3 avant de soumettre

• Tu sais finir la phrase « c'est la seule app qui... » sans parler de design
• La fonction principale se voit dès la première utilisation, sans chercher
• Aucun écran, texte, son ni visuel ne vient tel quel d'un template, dont tu as changé la logique
• Tu ne publies pas deux apps qui partagent le même code et le même concept
• Tes variantes (villes, équipes, thèmes) vivent dans une seule app
• Ton nom et ton sous-titre disent la fonction unique, pas la catégorie
• Ta première capture et ta description s'ouvrent sur ta différence
• Si ton app touche une catégorie citée par la 4.3(b), les notes de revue expliquent en deux phrases ce qui la distingue et comment le tester

La 4.3 se prévient au moment de choisir l'idée

Une app « de plus » dans une niche saturée pose deux problèmes. Apple peut la refuser au titre de la 4.3(b). Et si elle passe, elle affronte des apps installées depuis des années sans offrir de raison de la choisir.

La différenciation ne se rajoute donc pas au moment de soumettre. Elle se décide avant la première ligne de code, en réduisant ton idée à une fonction principale nette pour un public précis. C'est le cœur d'un MVP d'application iOS bien cadré, et la première étape de ma méthode de l'idée à l'App Store.

Choisir la bonne idée avant de coder

Dans le Kit iOS, la première étape du parcours sert précisément à ça : choisir l'idée, le public et le prix, avant d'écrire le code.

Tu as déjà reçu un refus 4.3 ? Le Kit Review Apple 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 te garantir la validation d'Apple, moi compris. Je peux t'aider à écarter dès le départ les idées qui feraient une app de trop.

Tu doutes encore de ton idée ? Le diagnostic gratuit part de ton projet, te dit quelle étape attaquer d'abord et t'envoie ma checklist anti-refus Apple. L'accueil montre ensuite comment créer une application mobile sans partir de zéro en choisissant l'idée avant d'écrire le code.

Questions fréquentes

Quelle est la différence entre 4.3(a) et 4.3(b) ?

La 4.3(a) vise la duplication : plusieurs versions de la même app, ou une app qui partage son code, sa fiche ou son concept avec d'autres à quelques détails près. La 4.3(b) vise la saturation : rien de nouveau dans une catégorie très fournie, comme les lampes torches.

Mon application créée avec l'IA sera-t-elle refusée pour 4.3 ?

Pas parce qu'elle est créée avec l'IA : Apple juge le résultat, pas l'outil. Le risque vient d'une idée générique que l'IA transforme en version moyenne de l'existant. Si ta fonction principale est unique et visible, l'origine du code ne pose pas de problème au titre de la 4.3.

Peut-on utiliser un template sans être refusé ?

Un template utilisé comme point de départ technique, puis transformé en profondeur, n'est pas le problème. Un template publié presque tel quel, avec un nouveau nom et de nouvelles couleurs, correspond exactement à ce que visent la 4.3(a) et la 4.2.6.

Faut-il changer de compte ou de Bundle ID après un refus 4.3 ?

Non. Changer d'identifiant ou de compte ne change pas l'app, et la 4.3(b) prévoit que des soumissions répétées d'apps de faible valeur peuvent mener à l'exclusion du programme développeur. La seule sortie durable est de modifier le produit, puis de le soumettre à nouveau.

Une application de rencontre ou de fonds d'écran peut-elle encore être acceptée ?

Oui, si elle offre une expérience réellement différente ou améliorée : c'est la condition posée par le texte d'Apple. Cette différence doit se voir dans l'app, la fiche et les notes de revue.