Refus Apple 4.2 « Minimum Functionality » : pourquoi votre app est refusée et comment la corriger

Apple refuse une app au titre de la règle 4.2 quand il estime qu'elle n'apporte pas assez par rapport à un simple site web : pas assez de fonctions, de contenu ou d'ergonomie propres à une application. C'est le refus typique des apps qui affichent un site dans une « boîte » (une WebView). Pour le corriger, il faut ajouter une vraie valeur d'application, comme des fonctions natives et une navigation pensée pour le mobile, puis expliquer ces changements à Apple lors de la resoumission.

Ce refus n'est pas définitif, mais aucune liste officielle de fonctions ne garantit l'acceptation. Voici comment le lire et y répondre.

Que dit exactement la règle 4.2 de l'App Store ?

La règle 4.2 de l'App Store est la règle « Minimum Functionality » des App Review Guidelines d'Apple : elle exige qu'une app offre davantage qu'un site web emballé. À la date d'octobre 2026, selon les App Review Guidelines (dernière mise à jour indiquée : 8 juin 2026), elle commence ainsi : « Your app should include features, content, and UI that elevate it beyond a repackaged website. »

En français : votre app doit proposer des fonctions, du contenu et une interface qui la placent au-dessus d'un site web reconditionné. Apple ajoute qu'une app qui n'est pas particulièrement utile, unique ou « app-like » (qui ne ressemble pas à une application) n'a pas sa place sur l'App Store.

La sous-règle 4.2.2 précise que, hors catalogues, une app ne doit pas être principalement un support marketing, une publicité, un extrait de site web (« web clippings »), un agrégateur de contenus ou une collection de liens.

La sous-règle 4.2.3 ajoute qu'une app doit fonctionner seule, sans exiger l'installation d'une autre app.

La règle laisse une large part d'appréciation à l'équipe de revue. C'est pour cela que deux apps proches peuvent recevoir des décisions différentes.

Pourquoi Apple refuse-t-il les apps « site web dans une boîte » ?

Apple refuse les apps « site web dans une boîte » au titre de la règle 4.2 parce qu'elles n'offrent rien de plus que le site ouvert dans Safari. Une WebView est un composant qui affiche une page web à l'intérieur d'une application. Beaucoup d'outils l'utilisent : convertisseurs « site vers app », certains outils no-code, ou encore une app Lovable ou Bolt emballée telle quelle.

Utiliser une WebView n'est pas interdit en soi. Des frameworks comme Capacitor reposent sur ce principe et des apps de ce type sont publiées sur l'App Store. Le problème apparaît quand l'app n'est que le site, sans rien de plus. Pour le testeur d'Apple, rien ne justifie alors de l'installer plutôt que d'ouvrir le site dans Safari.

Les signaux qui attirent souvent ce refus :

• l'app affiche la même chose que le site, menu « burger » web compris ;
• la barre d'adresse, les bandeaux cookies ou les pieds de page web restent visibles ;
• les liens ouvrent des pages externes au lieu de rester dans l'app ;
• l'app ne fait rien sans connexion internet, pas même un message clair ;
• aucune fonction ne tire parti du téléphone.

Où trouver et comment lire le message de refus Apple ?

Le message de refus Apple se trouve dans la section App Review de l'app dans App Store Connect ; il indique la règle concernée et décrit le problème. Selon l'aide App Store Connect, sélectionnez l'app, cliquez sur le lien signalant des problèmes non résolus, puis sur Resolve à côté de la soumission.

Lisez le message en entier, pas seulement le numéro de règle. Repérez trois choses :

1. La règle citée : par exemple « Guideline 4.2 », suivie de son intitulé. Un même message peut citer plusieurs règles.
2. La description du problème : Apple écrit souvent que l'app offre une expérience trop proche d'un site web.
3. Les pistes éventuelles : le message suggère parfois le type de fonctions attendues. Notez-les mot pour mot.

Comment corriger un refus Apple 4.2 ?

Pour corriger un refus Apple 4.2, il faut donner à l'app une valeur propre à une application : fonctions natives utiles, navigation mobile et contenu ou service absent du site. Aucune fonction n'est magique : Apple évalue l'expérience d'ensemble sur un téléphone.

Ajouter des fonctions natives utiles

Une fonction native est une fonction qui utilise directement les capacités de l'iPhone (notifications, caméra, Face ID, stockage local). Les plus courantes :

• Notifications push : rappels, alertes de commande, nouveaux messages. Elles doivent servir l'utilisateur, pas seulement faire du marketing.
• Connexion native : Face ID pour se reconnecter, ou un service de connexion intégré. Attention, la règle 4.8 encadre l'usage des connexions tierces (voir le tableau plus bas).
• Partage natif : le bouton de partage iOS pour envoyer un contenu par message ou e-mail.
• Appareil photo et photos : scanner un document, ajouter une photo de profil, joindre un justificatif.
• Fonctionnement hors ligne : afficher les dernières données consultées, ou au minimum un écran clair quand le réseau manque.

Chaque fonction doit avoir un usage réel dans votre app. Une fonction gadget n'aide pas.

Adapter la navigation au mobile

Remplacez le menu web par une barre d'onglets en bas de l'écran, comme dans la plupart des apps iOS. Supprimez les éléments purement web : pied de page, bandeau cookies du site, liens vers l'extérieur. Vérifiez les zones de l'écran (encoche, barre du bas) et le comportement du bouton retour.

Proposer un contenu ou un service propre à l'app

Demandez-vous ce que l'app permet de faire que le site ne permet pas. Un espace client avec suivi, un mode de consultation rapide, des favoris enregistrés sur le téléphone : ce type de valeur montre que l'app a sa propre raison d'exister.

Comment répondre à Apple et resoumettre après un refus 4.2 ?

Après un refus 4.2, il faut répondre à App Review dans App Store Connect en décrivant les changements, puis envoyer un nouveau build corrigé. Une fois l'app corrigée, ces deux actions comptent.

Répondre dans App Store Connect. Depuis la page de la soumission, cliquez sur Reply to App Review. Selon l'aide App Store Connect, vous pouvez échanger avec Apple et joindre des fichiers, comme des captures d'écran, jusqu'à la resoumission. Décrivez précisément ce qui a changé et où le trouver dans l'app. Si une fonction exige un compte, fournissez un compte de démonstration dans les notes de revue.

Resoumettre un nouveau build. Pour un refus 4.2, le problème est dans l'app elle-même : il faut donc envoyer une nouvelle version. Selon la section « After You Submit » des App Review Guidelines, le même build ne peut être resoumis que si le refus portait sur les métadonnées (fiche, captures, description).

Faire appel si vous pensez qu'il y a erreur. L'App Review Board est l'instance d'Apple qui examine les appels contre les décisions de revue, via un formulaire de contact dédié. Selon l'aide App Review, il faut d'abord répondre au message de refus, puis expliquer précisément en quoi l'app respecte les règles citées. Un seul appel par app refusée, et pas d'appel si vous avez déjà corrigé et resoumis. Pour un site simplement emballé, corriger l'app reste la voie la plus réaliste.

La décision finale appartient à Apple, qui signale aussi dans les App Review Guidelines que des refus répétés pour la même règle allongent la revue. Mieux vaut une resoumission soignée que plusieurs essais rapides.

Quels refus Apple sont souvent confondus avec la règle 4.2 ?

Les refus Apple les plus souvent confondus avec la 4.2 sont la 4.3 (spam), la 2.1 (app incomplète), la 4.8 (services de connexion), la 5.1.1(v) (suppression de compte) et la 3.1.1 (achat intégré). Vérifiez la règle citée, car les correctifs n'ont rien à voir.

Une même app peut cumuler plusieurs refus. Traitez-les tous dans la même resoumission.

Quand faut-il reconstruire l'app plutôt que la réemballer ?

Reconstruire tout ou partie de l'app devient pertinent quand quelques fonctions ajoutées ne suffisent pas à dépasser le simple site web emballé, notamment dans ces cas :

• le site n'a pas été pensé pour le mobile et chaque écran doit être repris ;
• l'outil no-code utilisé ne donne pas accès aux fonctions natives ;
• l'app a déjà été refusée plusieurs fois malgré des correctifs ;
• vous prévoyez des fonctions avancées : hors ligne complet, géolocalisation, paiements.

Dans ce cas, une app construite avec Capacitor ou React Native, en réutilisant votre code ou vos données quand c'est possible, part sur une base plus solide qu'un emballage ajusté refus après refus.

Se faire accompagner après un refus Apple

L'offre GUIGUI Tech App refusée par Apple : on la débloque commence par un diagnostic à 500€ HT, réalisé en 2 jours ouvrés : analyse du message de refus, de l'app et des correctifs à prévoir, chiffrés ensuite séparément. Pour une app Lovable, voyez l'offre Votre app Lovable sur iPhone et Android ; pour un site React, Next.js ou Vue.js, la transformation site vers app avec Capacitor.