Guideline 4.3(a) Design Spam : corriger le rejet, avec 4.3(b) et 4.2.6 pour les apps template et IA (2026)

Un rejet pour Guideline 4.3(a) Design Spam est l'un des messages d'App Review les plus difficiles à traiter, car il indique rarement à quelle app la vôtre ressemble. Il touche bien plus souvent les apps issues de templates, les apps en marque blanche pour des clients et les apps générées par IA. Ce guide distingue la 4.3(a) de la 4.3(b) et de la 4.2.6, montre comment d'autres développeurs ont surmonté ce rejet, et vous donne un modèle de réponse ainsi qu'une checklist à compléter avant de soumettre à nouveau. Pour les autres types de rejet, consultez le guide des rejets guideline par guideline.

Que signifie la Guideline 4.3(a) Design Spam ?

La Guideline 4.3(a) signifie qu'Apple considère votre soumission comme substantiellement identique à une app déjà soumise : soit plusieurs Bundle IDs d'une même app, soit une quasi-copie de l'app de quelqu'un d'autre. La solution consiste à regrouper les doublons ou à rendre l'expérience principale clairement différente.

En novembre 2026, les App Review Guidelines indiquent : « Ne créez pas plusieurs Bundle IDs pour la même app (par exemple, en soumettant une app de carte distincte pour chaque ville du monde au lieu d'une seule carte mondiale permettant de rechercher n'importe quelle ville). » L'alternative proposée par Apple : « envisagez de soumettre une seule app et de proposer les variantes via achat intégré ». La 4.3(a) porte l'icône de clé, elle s'applique donc aussi à la notarisation des apps iOS et iPadOS distribuées en dehors de l'App Store.

Le texte de rejet que reçoivent généralement les développeurs est : « Guideline 4.3(a) - Design - Spam. We noticed your app shares a similar binary, metadata, and/or concept as apps submitted to the App Store by other developers, with only minor differences. » (en substance : votre app partage un binaire, des métadonnées et/ou un concept similaires à des apps soumises par d'autres développeurs, avec seulement des différences mineures). Cette phrase contient trois déclencheurs (binaire, métadonnées, concept), et chacun d'eux peut à lui seul provoquer le rejet.

Quelle différence entre 4.3(a), 4.3(b) et 4.2.6 ?

La 4.3(a) concerne les doublons, la 4.3(b) les apps qui n'apportent rien de nouveau dans une catégorie déjà encombrée, et la 4.2.6 les apps construites à partir d'un template et soumises depuis le mauvais compte. Chacune exige une correction différente : vérifiez donc d'abord le numéro exact de la guideline dans votre rejet.

Le texte actuel de la 4.3(b) prévient également qu'Apple « pourra retirer ces apps de l'App Store à l'avenir si elles ne sont pas mises à jour, améliorées ou si elles n'attirent pas d'utilisateurs », et que des catégories à faible effort, comme les jeux à boire ou les apps de pets, peuvent entraîner une exclusion de l'Apple Developer Program en cas de soumissions répétées. Pour les autres règles récemment révisées par Apple, consultez notre article sur les changements des App Review Guidelines d'octobre 2026.

Pourquoi les apps issues de templates ou générées par IA sont-elles signalées comme spam ?

Les apps issues de templates ou générées par IA sont signalées parce que beaucoup partagent le même code de départ, les mêmes mises en page d'écrans et des textes de fiche similaires, ce qui correspond aux trois déclencheurs : binaire, métadonnées et concept. Être propriétaire du code n'exempte pas une app si le résultat ressemble à des centaines d'autres.

Les app builders IA produisent souvent le même onboarding, la même barre d'onglets et le même ensemble de fonctionnalités génériques (« suivez vos habitudes, obtenez des insights IA »), et la description App Store générée se ressemble souvent tout autant. Si vous avez publié via un builder, vérifiez qui apparaît comme vendeur. La 4.2.6 précise que les services de templates « ne doivent pas soumettre d'apps au nom de leurs clients » : l'app doit donc être publiée sous le compte développeur du propriétaire du contenu. Notre guide de publication Base44 et notre guide de publication Lovable détaillent ce qui reste à votre charge après l'export.

Comment d'autres développeurs ont-ils corrigé un rejet 4.3(a) ?

Les cas rapportés publiquement montrent que les changements visuels seuls fonctionnent rarement. Regrouper les apps en double et rédiger une réponse précise sur ce qui rend l'app différente donne de meilleurs résultats.

• Fusion dans une app existante (GitHub). Une équipe publiant une app VoIP basée sur Linphone a indiqué dans l'issue #936 de linphone-iphone qu'un nouveau jeu d'icônes et une nouvelle palette de couleurs n'avaient pas suffi à lever la 4.3(a). Elle en a conclu que le conflit venait d'une autre app basée sur Linphone sur le même compte. Elle a intégré les changements à cette app existante sous forme de mise à jour, qui a été validée « presque immédiatement ».
• Expliquer ce qui rend l'app unique (Godot Forum). Un développeur de jeux sur le Godot Forum soupçonnait que le binaire du moteur partagé correspondait à d'autres jeux Godot. Réduire la taille du build et expliquer qu'il utilisait Godot ont tous deux été rejetés. Une réponse « listant les points clés qui, selon moi, rendaient mon jeu agréable et unique par rapport aux autres jeux du même genre » a permis la validation.
• Les captures d'écran ne suffisaient pas (Apple Developer Forums). Dans un fil des Apple Developer Forums, un développeur explique qu'un représentant d'Apple a pointé les captures d'écran, et que les « métadonnées » peuvent désigner le titre, le sous-titre, les mots-clés ou les captures d'écran. Des captures entièrement nouvelles ont pourtant reçu le même rejet, pour une mise à jour d'une app existant depuis 2 à 3 ans.

Le point commun : les changements cosmétiques (icônes, couleurs, captures d'écran) ont échoué dans les trois cas. Ce qui a fonctionné, c'est de supprimer le doublon sur le compte ou de donner au reviewer des raisons concrètes, au niveau des fonctionnalités, qui différencient l'app.

Comment corriger un rejet 4.3(a) étape par étape ?

Pour corriger un rejet 4.3(a), trouvez d'abord le doublon, apportez ensuite de vrais changements au produit, puis répondez à l'App Review avec des éléments précis avant de soumettre à nouveau. Resoumettre le même build avec une nouvelle icône est la façon la plus courante d'être rejeté une nouvelle fois.

1. Lisez le numéro exact de la guideline dans la section App Review d'App Store Connect. S'il s'agit de la 4.2.6 ou de la 4.3(b), suivez plutôt la ligne correspondante du tableau ci-dessus.
2. Listez toutes les apps de votre compte, en ligne ou retirées, qui partagent du code, un template, un concept ou un design avec l'app rejetée. Si vous en trouvez une, fusionnez-les en une seule app avec des variantes intégrées, ou publiez les changements sous forme de mise à jour de l'app en ligne.
3. Recherchez les mots-clés de votre catégorie sur l'App Store et notez les premiers résultats. Écrivez ce que votre app fait et qu'aucune d'entre elles ne fait.
4. Modifiez au moins un parcours principal (source de données, fonctionnalité principale, modèle d'interaction), pas seulement le thème.
5. Réécrivez le nom, le sous-titre, les mots-clés, la description et les captures d'écran pour qu'ils décrivent vos fonctionnalités spécifiques, sans aucun texte générique de template restant.
6. Répondez dans App Store Connect à l'aide du modèle ci-dessous. La page App Review d'Apple propose aussi des rendez-vous Webex de 30 minutes si vous souhaitez interroger directement un reviewer sur les guidelines.
7. Si vous pensez que le reviewer a mal compris l'app, déposez un recours auprès de l'App Review Board. Apple demande de « ne soumettre qu'un seul recours par soumission n'ayant pas passé la review » et de répondre d'abord aux demandes d'informations.

Que doit contenir la réponse à l'App Review ?

Une bonne réponse nomme les fonctionnalités précises qui différencient l'app, confirme qu'il n'y a aucune app en double sur votre compte et indique au reviewer où chaque différence est visible. Restez bref, factuel et courtois.

Hello App Review,

Thank you for the feedback on Guideline 4.3(a). We have reviewed our account
and confirm [App Name] is our only app in this category. [We removed /
merged "Old App" into this app in version X.Y.]

What [App Name] does that similar apps do not:
1. [Feature] - e.g. syncs with the user's school timetable via [API];
   see Home > Schedule.
2. [Feature] - e.g. offline lesson plans authored by our team, not
   generated or scraped; see Library.
3. [Feature] - e.g. teacher-to-parent messaging; see the demo account.

This version also changes [core flow] and replaces all metadata and
screenshots to reflect these features.

Demo account: [username] / [password]

We are happy to provide more detail or join a call.

Thank you,
[Name]

Si une fonctionnalité nécessite une connexion, fournissez au reviewer des identifiants fonctionnels. Notre guide du compte de démo pour la review App Store explique comment en configurer un.

Que doit couvrir une checklist de différenciation avant de resoumettre ?

Une checklist de différenciation doit couvrir votre compte, votre binaire, vos métadonnées et votre concept, les quatre éléments examinés par la 4.3. Cochez chaque point avant de cliquer à nouveau sur Submit for Review.

• Compte : aucune autre app, en ligne ou retirée, ne partage le même template, concept ou design.
• Compte : l'app est soumise depuis le compte développeur du propriétaire du contenu (4.2.6).
• Binaire : les écrans d'exemple du template, les données de démo et le branding provisoire ont été supprimés.
• Binaire : au moins une fonctionnalité principale existe que les premiers résultats de la catégorie n'ont pas.
• Métadonnées : le nom, le sous-titre et les mots-clés décrivent votre valeur spécifique, pas la catégorie en général.
• Métadonnées : les captures d'écran montrent vos fonctionnalités distinctives dès les deux premières images.
• Concept : vous pouvez expliquer en une phrase pourquoi un utilisateur choisirait cette app plutôt que les cinq premiers résultats.
• Notes de review : les différences et un compte de démo y sont indiqués, pour que le reviewer n'ait pas à les chercher.

Si vous avez été rejeté plus d'une fois au titre de la 4.3 et ne savez pas quoi changer, notre service de soumission App Store prépare la review et traite avec vous les retours de rejet, pour $599 couvrant les deux stores (les frais de compte développeur sont en sus).