Refus App Store pour les règles 4.2 et 4.3 : fonctionnalité minimale et spam, expliqués (2026)

La règle 4.2 (Minimum Functionality) refuse les apps qui n’en font pas assez par elles-mêmes : site web reconditionné, collection de liens, écran unique sans profondeur, app générée à partir d’un modèle commercial. La règle 4.3 (Spam) refuse les apps qui se dupliquent, comme une même app publiée sous plusieurs identifiants de bundle, ou qui n’apportent rien à une catégorie déjà saturée. Pour passer, donnez à l’app une valeur native qui fonctionne sans votre site, une raison d’être distincte de toutes les autres apps (y compris les vôtres), et expliquez cette différence à App Review dans une réponse courte et factuelle avant d’envisager un appel.

Points clés

• La 4.2 juge l’app elle-même : elle doit être plus qu’un site web, un catalogue de liens ou une action triviale, et offrir une valeur durable.
• La 4.3 juge l’app par comparaison : pas plusieurs identifiants de bundle pour la même app, pas de quasi-copie de ce qui existe déjà en abondance.
• Widgets, Live Activities et App Clips prolongent une app ; les règles attendent qu’ils se rattachent à son contenu, donc l’app principale doit tenir debout seule.
• Les apps issues d’un modèle ou d’un générateur (4.2.6) doivent être soumises par le fournisseur du contenu, ou regroupées dans une seule app « sélecteur ».
• Répondez d’abord dans la section App Review d’App Store Connect (4 000 caractères au plus, pièces jointes possibles) ; ne saisissez l’App Review Board que si l’app a été mal comprise.
• Un portefeuille d’apps de niche est légitime quand chaque app résout un problème différent ; les variantes d’une même app vont dans une seule app.

Ce que disent vraiment les règles 4.2 et 4.3

Les deux règles figurent dans la section 4, Design, des App Store Review Guidelines, publiées en anglais (version citée ici : mise à jour du 8 juin 2026 ; les extraits sont traduits librement). Les messages de refus les citent par leur numéro, parfois avec un sous-point : mieux vaut savoir exactement ce que chacune couvre.

Règle 4.2 : Minimum Functionality

Le texte principal de la 4.2 demande des fonctions, du contenu et une interface qui élèvent l’app au-delà d’un « site web reconditionné » (repackaged website). Il ajoute qu’une app qui n’est pas particulièrement utile, unique ou « app-like » n’a pas sa place sur l’App Store, et qu’une app sans valeur de divertissement durable ou sans utilité suffisante peut être refusée. Les sous-points précisent :

Règle 4.3 : Spam

La règle 4.3 comporte deux volets :

• 4.3(a), les doublons. Ne créez pas plusieurs identifiants de bundle pour la même app. L’exemple d’Apple : une app de carte par ville au lieu d’une seule carte mondiale. Les variantes par lieu, équipe sportive ou université doivent vivre dans une seule app, débloquées par des options ou un achat intégré.
• 4.3(b), les catégories saturées. Ne soumettez pas d’app impossible à distinguer de ce qui existe déjà en abondance. Apple cite les apps de rencontre, lampes torches, effets sonores, fonds d’écran, minuteurs simples et voyance : de nouvelles soumissions n’y sont acceptées que si elles offrent une expérience « sensiblement différente ou améliorée ». Les soumissions répétées d’apps de faible qualité peuvent mener à l’exclusion de l’Apple Developer Program.

La page App Review d’Apple range les deux parmi les problèmes courants. Sous « Not enough lasting value », elle prévient qu’une app qui offre peu de fonctions ou de contenu, ou qui ne concerne qu’un « tout petit marché de niche », peut ne pas être acceptée. Sous « Repeated submission of similar apps », elle conseille de regrouper les apps quasi identiques en une seule.

Pourquoi une app est refusée pour la 4.2

L’examinateur juge ce qu’il voit dans le build, sur un appareil. Les situations qui mènent à un refus pour fonctionnalité minimale se ressemblent :

• Les apps web encapsulées. Une WKWebView qui charge votre site, avec une barre d’onglets par-dessus : c’est le cas d’école. La page App Review d’Apple rappelle qu’un site servi dans une app, un contenu web non adapté à iOS et des interactions web limitées ne font pas une app de qualité. Le problème n’est pas la technologie web en soi, mais une app qui se contente de refléter un site.
• Les apps vitrines et de liens (4.2.2). Une plaquette d’entreprise, une liste de liens, un lecteur RSS pour un seul blog, une page de boutons de contact.
• Les utilitaires trop minces. Un écran, une action, rien d’enregistré, aucune raison de revenir : un convertisseur isolé, un compteur, une fiche de référence statique. Plus la tâche est simple, plus le reste de l’app doit compenser.
• Les apps issues de modèles ou de générateurs (4.2.6). Agences et outils de création d’apps qui publient une app par client à partir du même modèle, sous leur propre compte. Les solutions prévues par Apple : le client soumet l’app sous son propre compte, ou le fournisseur publie une seule app agrégée avec une entrée par client.
• Les apps qui dépendent d’une autre app (4.2.3). Une app compagnon qui ne fait rien tant qu’une autre app n’est pas installée.
• Une première impression incomplète. Des écrans vides sans contenu d’exemple, ou des fonctions derrière une connexion sans compte de démo, font paraître l’app plus mince qu’elle ne l’est.

Live Activities, widgets et App Clips : une app peut-elle se limiter à cela ?

Des recherches comme « live activity guideline 4.2 » viennent de développeurs dont l’app est surtout une Live Activity ou un widget, avec un écran principal qui se résume à un bouton « Démarrer ». Aucune règle ne cite les Live Activities dans la 4.2 ; voici ce qu’Apple documente réellement :

• Règle 2.5.16 : les widgets, extensions et notifications doivent se rapporter au contenu et aux fonctions de l’app. Ce sont des prolongements d’une app, pas des substituts.
• Les Live Activities se construisent avec ActivityKit, dans une extension de widget. Les Human Interface Guidelines les réservent aux tâches et événements qui ont un début et une fin, et ActivityKit les termine au bout de huit heures au plus (elles peuvent rester jusqu’à quatre heures de plus sur l’écran verrouillé). Elles ne doivent afficher ni publicité ni promotion, et la règle 4.5.3 interdit de s’en servir pour du spam.
• Les widgets affichent un contenu consultable d’un coup d’œil, rafraîchi périodiquement, et renvoient vers la bonne partie de l’app ; les HIG notent que reproduire l’icône de l’app n’apporte pas grand-chose.
• Les App Clips sont une partie légère d’une app complète, pour une tâche rapide ou une démo ; ils accompagnent l’app, ils ne la remplacent pas.

Notre lecture, qui n’engage que nous et pas Apple : l’examinateur ouvre d’abord l’app principale ; si elle ne sert qu’à lancer une Live Activity ou à héberger un widget, un refus 4.2 est probable. La solution consiste à donner une raison d’ouvrir l’app : historique des sessions, réglages qui changent ce que suit la Live Activity, statistiques, chronologie, export des données. La Live Activity ou le widget devient alors la surface pratique d’une vraie app.

Pourquoi une app est classée comme spam (4.3)

Un refus 4.3 porte rarement sur une app isolée. Il compare la soumission au reste de l’App Store et, pour les doublons, aux autres apps que vous soumettez :

• Une app, plusieurs noms. Le même binaire avec un autre thème, une autre ville, une autre langue ou un autre public, chacun sous son propre identifiant de bundle : c’est exactement l’exemple de la 4.3(a).
• Les modèles repeints. Un code source acheté ou un modèle générique republié avec de nouvelles couleurs et une nouvelle icône ; écrans, parcours et descriptions restent reconnaissables.
• Les catégories encombrées, sans nouveauté. Une énième lampe torche, app de fonds d’écran ou minuteur simple, avec les mêmes fonctions que des centaines d’autres (4.3(b)).
• Des fiches qui se ressemblent. Plusieurs apps d’un même compte avec des captures, descriptions et mots-clés presque identiques font passer des apps différentes pour des doublons.

Deux règles voisines à ne pas confondre : copier l’app d’un autre, son nom ou son interface relève de la 4.1 (Copycats), et le bourrage de mots-clés de la 2.3 (Accurate Metadata). Notre checklist de soumission App Store couvre ces refus et les autres motifs fréquents.

Comment faire passer une app à la 4.2

La fonctionnalité minimale ne se mesure pas au nombre de fonctions. La vraie question : quelqu’un rouvrira-t-il cette app la semaine prochaine, et pourrait-elle aussi bien exister sous forme de site ? Ces changements vont dans le bon sens :

Ajoutez des intégrations parce qu’elles servent l’usage, pas pour décorer : un widget qui ne fait que reprendre l’icône de l’app n’impressionnera personne. Si votre produit est d’abord un service web, demandez-vous tôt si une app native se justifie ; notre comparatif SwiftUI, Flutter ou React Native aide à choisir comment la construire. Et testez le build exact qu’examinera Apple, depuis une installation neuve, via TestFlight : les tests externes passent eux aussi par une vérification bêta.

Pour une première version, le périmètre compte plus que la finition. Un MVP doit être la plus petite app qui apporte déjà une valeur durable par elle-même, pas une coquille qui promet des fonctions pour plus tard.

Publier beaucoup d’apps de niche en gardant chacune distincte

Develak publie plus de 30 apps sur l’App Store, la plupart pour une niche précise : la 4.3 est donc une règle à laquelle nous pensons avant d’écrire la moindre ligne de code. Partager une architecture, un système de design et des composants entre apps relève de la bonne ingénierie, et ce n’est pas ce que vise la 4.3. Ce qui compte, c’est que chaque app réponde à un besoin différent. Deux apps de sport de notre catalogue illustrent l’idée : TenRing enregistre les scores de tir à l’arc et la position des flèches, Cragly tient le journal et les statistiques des séances d’escalade. Même studio, mais des utilisateurs, des données et des écrans différents.

Les règles que nous appliquons avant de lancer une nouvelle app :

1. Un problème par app. Si deux idées ne diffèrent que par le public, la région ou le thème, c’est une seule app avec des options, pas deux apps.
2. Un modèle de données propre. Si les entités et les écrans principaux sont ceux d’une autre app, la raison d’être l’est probablement aussi.
3. Une valeur native adaptée à la niche. Les fonctions qu’un utilisateur de cette niche attend, disponibles hors ligne.
4. Une fiche App Store à elle. Nom, icône, sous-titre, captures et description écrits pour cette app, pas adaptés d’une app sœur. Une fiche distincte, c’est aussi une meilleure optimisation App Store (ASO).
5. Des notes de vérification qui énoncent la différence. Une ou deux phrases sur le public visé et ce que l’app fait que les autres ne font pas.

Répondre dans App Review (l’ancien Resolution Center)

Les messages de refus arrivent dans la section App Review de la page de l’app dans App Store Connect, longtemps appelée Resolution Center. D’après l’aide d’App Store Connect, il suffit d’ouvrir le problème non résolu, de cliquer sur Resolve puis sur Reply to App Review ; la réponse accepte jusqu’à 4 000 caractères et des pièces jointes (captures, documents). Les rôles Account Holder, Admin et App Manager peuvent répondre. Si le refus ne portait que sur les métadonnées, vous pouvez soumettre à nouveau le même build une fois la correction faite.

Une bonne réponse à un refus 4.2 ou 4.3 est courte et vérifiable :

• Remerciez l’examinateur et rappelez la règle citée, pour que l’échange reste centré sur un seul sujet.
• Décrivez en trois ou quatre points concrets ce que l’app fait et qu’un site ou une app sœur ne fait pas.
• Donnez les étapes exactes pour atteindre ces fonctions, un compte de démo si besoin, et joignez un court enregistrement d’écran.
• Si vous avez modifié l’app, dites ce qui a changé et dans quel numéro de build.
• Restez factuel. Comparer avec d’autres apps acceptées aide rarement : chaque app est examinée pour elle-même.

Un cas particulier : pour une mise à jour corrective d’une app déjà publiée, les règles prévoient que les correctifs ne sont pas retardés pour des manquements aux règles, sauf problèmes juridiques ou de sécurité. Indiquez à App Review, dans l’échange, que vous souhaitez en bénéficier et que vous traiterez le problème dans la prochaine soumission.

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

Un appel s’adresse à l’App Review Board via le formulaire d’appel d’Apple, pas via le fil de messages. La page App Review d’Apple le réserve aux cas où vous estimez que l’examinateur a mal compris le concept et les fonctions de l’app, ou que vous avez été traité injustement. Elle demande d’expliquer précisément pourquoi l’app respecte les règles, de ne déposer qu’un appel par soumission refusée, et de répondre d’abord à toute demande d’information en attente.

• Faites appel si l’examinateur est passé à côté de fonctions bien présentes (derrière l’accueil, une connexion ou un réglage), ou a traité une app réellement différente comme un doublon, et que votre réponse dans l’échange n’a rien réglé.
• Ne faites pas appel si l’app est vraiment un site encapsulé, un modèle repeint ou une variante d’une autre app du compte. Corrigez le produit : ajoutez de la valeur native, ou fusionnez les variantes en une seule app.
• Demandez conseil avant un gros changement : Apple propose des rendez-vous App Review de 30 minutes sur Webex pour discuter des règles.

Soumettre à nouveau le même build sous un autre nom n’est pas une stratégie. Les règles précisent qu’une app refusée à répétition pour le même manquement est examinée plus lentement, et la 4.3(b) prévient que des soumissions répétées de faible qualité peuvent coûter le compte développeur.

Comment Develak traite les règles 4.2 et 4.3

Pour nos apps comme pour nos clients, nous vérifions la 4.2 et la 4.3 dès l’idée, pas après un refus : l’app fonctionne-t-elle hors ligne, fait-elle quelque chose qu’un site ne peut pas faire, se distingue-t-elle de tout ce que contient déjà le compte ? Avant la soumission, nous rédigeons des notes de vérification qui expliquent la raison d’être de l’app et comment la tester. Nul ne peut garantir une validation, puisque seule Apple décide, mais cette méthode évite les mauvaises surprises. Si vous préparez une app, notre offre de développement d’application iOS couvre la réalisation et les échanges avec App Review, ou parlez-nous de votre projet.

FAQ