Guideline 4.2 Minimum Functionality : application refusée

La guideline 4.2, « Minimum Functionality », refuse une app qui n'offre rien de plus qu'un site web, ou trop peu pour qu'on la garde. Le remède n'est pas d'empiler des fonctions natives : c'est d'en placer une au cœur de l'usage, puis de dire au reviewer où la trouver. Le correctif passe presque toujours par un nouveau build.

Je publie mes propres apps iOS : Solys, TradaZen et Nolera sont sur l'App Store. Ce guide s'appuie sur le texte officiel d'Apple, lu le 15 octobre 2026, et sur des refus 4.2 publiés par des développeurs sur les forums d'Apple. Les apps refusées citées plus bas sont des exemples. Pour la vue d'ensemble de tous les motifs, lis plutôt pourquoi Apple refuse une app.

Que dit la guideline 4.2 ?

La 4.2 se trouve dans la section 4, « Design », des App Review Guidelines. Sa première phrase pose le critère : « Your app should include features, content, and UI that elevate it beyond a repackaged website. » Autrement dit, ton app doit offrir des fonctions, du contenu et une interface qui la placent au-dessus d'un site web remis dans une boîte.

Le texte ajoute deux idées. Une app qui n'est pas vraiment utile, unique ou « app-like » n'a pas sa place sur l'App Store. Et une app qui n'offre ni divertissement durable ni utilité suffisante peut être refusée. La 4.2 juge donc deux choses : la différence avec le web, et la quantité de valeur.

Les sous-règles que le message peut citer

Sous-règle	Ce qu'Apple demande	Le refus typique
4.2	Aller au-delà d'un site web	Site affiché dans une WebView
4.2.1	Une vraie expérience en réalité augmentée	Un modèle 3D posé dans la vue AR
4.2.2	Pas seulement du marketing ou des liens	App vitrine, agrégateur, liens
4.2.3	Une app autonome, des téléchargements clairs	App qui exige une autre app
4.2.6	Pas d'app tirée d'un modèle commercial	Template soumis par un prestataire

Trois précisions. La 4.2.2 fait une exception pour les catalogues : « Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links. » Un catalogue de produits peut donc passer. Une plaquette publicitaire, non.

La 4.2.3 a deux alinéas. Le (i) demande que l'app fonctionne seule, sans installer une autre app. Le (ii) demande, si l'app doit télécharger des ressources au premier lancement, d'annoncer la taille du téléchargement et de demander l'accord avant.

La 4.2.6, sur les modèles commerciaux et les services de génération d'apps, est détaillée dans le guide de la guideline 4.3, parce qu'elle va de pair avec la règle anti-spam.

Les deux messages 4.2 les plus fréquents

Le message d'Apple s'ouvre sur l'intitulé « Guideline 4.2 - Design - Minimum Functionality ». La suite dit lequel des deux problèmes le reviewer a vu. Voici deux formulations publiées par des développeurs sur les forums d'Apple. Elles datent de quelques années : le texte exact a pu changer, pas les deux familles.

L'app ressemble à un site. « Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience. » Ce message, publié sur les forums d'Apple, contient une phrase décisive : « Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store. »

L'app est trop maigre. « We found that the usefulness of your app is limited by the minimal amount of content or features it includes. » Ce second message demande de revoir le concept, et reconnaît qu'aucune règle chiffrée ne définit ce qui est utile ou divertissant.

Ajouter des notifications, la localisation et un bouton de partage à un site encapsulé ne suffit pas : Apple l'a écrit dans ses propres refus.

Quatre cas typiques de refus 4.2

Les quatre cas ci-dessous sont des exemples construits pour illustrer la règle, pas des apps réelles.

Le site web encapsulé

Exemple : un club de sport affiche son site mobile dans une WebView, avec une barre d'onglets native par-dessus. Le planning, la réservation et le compte sont des pages web. Le reviewer y retrouve ce que Safari lui montrerait. Apple le dit sur sa page App Review : un site servi dans une app iOS, un contenu web non adapté à iOS ou des interactions web limitées ne font pas une app de qualité.

Ce que je ferais : reconstruire en natif les écrans du geste principal, ici le planning et la réservation. Puis ajouter ce que le site ne sait pas faire : un rappel avant la séance, le planning consultable sans réseau, la prochaine séance dans un widget.

L'application trop simple

Exemple : une app qui affiche une citation par jour, et rien d'autre. On en fait le tour en dix secondes. La 4.2 parle de « lasting entertainment value or adequate utility » : une valeur qui dure, ou une utilité suffisante. Pour corriger, ajoute de la profondeur au geste principal, pas des écrans autour. Ici : un historique, des favoris, un rappel à l'heure choisie, un widget sur l'écran d'accueil.

L'application générée par IA, sans rien de natif

Exemple : un champ de texte, un bouton, une réponse d'IA affichée en texte brut. Apple ne juge pas l'outil, mais ce qui arrive sur l'écran du reviewer. Si l'expérience tient dans une page web, la 4.2 a de bonnes chances de tomber.

Je détaille ce que l'IA fait bien et ce qu'elle rate dans créer une application avec l'IA. Le format produit par chaque générateur, application web ou projet mobile, est comparé dans Lovable, Rork ou FlutterFlow.

La coquille en attente de contenu

Exemple : une place de marché sans annonces, un annuaire vide, un fil qui affiche « Bientôt disponible ». Le reviewer ouvre une app qui n'a rien à montrer. Ce cas touche aussi la 2.1, qui refuse le contenu provisoire : voir le guide de la guideline 2.1. Envoie l'app quand elle a du contenu réel, ou fournis un compte de démonstration déjà rempli.

Le test que je fais : « Et dans Safari ? »

Avant d'envoyer, je me demande si un site web pourrait offrir la même fonction principale. Si oui, l'app est exposée à la 4.2. Voici ma grille pour juger une fonction native. Une fonction compte quand elle sert le geste principal, pas quand elle décore.

Fonction	Elle compte quand...	Elle ne suffit pas quand...
Notifications	Elles apportent une information attendue	Elles relaient tes articles
Hors ligne	Le contenu principal reste utilisable	Seul un écran d'erreur s'affiche
Widget	Il montre une donnée propre à la personne	Il affiche ton logo
Partage	On envoie du contenu vers ton app	Il partage seulement un lien
Caméra, capteurs	Ils font partie du geste principal	Ils ouvrent ton site
Données locales	L'app calcule, range et se souvient	Tout vit sur une page web

Les recommandations d'Apple vont dans le même sens. Un widget affiche un contenu d'actualité, lisible d'un coup d'œil. Une notification apporte une information utile, en peu de mots, et ne sert pas à pousser vers une tâche dans l'app.

Ce que mes apps font qu'un site ne fait pas

Je conçois chaque app autour d'une fonction principale qui n'existe pas dans un navigateur, ou d'une valeur qui fait revenir.

• Solys est un réveil. La sonnerie passe par AlarmKit, le service d'alarme d'iOS 26 : elle traverse le mode silencieux, comme le réveil d'Apple. Pour l'arrêter, il faut gagner un mini-jeu, et les apps choisies restent en pause après le réveil. Aucune page web ne fait sonner un iPhone en silencieux.
• TradaZen est un simulateur de trading : un vrai graphique à une vraie date, une décision, des bougies qui se révèlent, des duels classés et un rang qui progresse. Ici, ce n'est pas une fonction native qui porte l'app. C'est la valeur de divertissement durable dont parle la 4.2.
• Nolera est un dressing : tu photographies tes vêtements, l'app les détoure et les range, puis te propose une tenue chaque matin. La caméra fait partie du geste principal. Elle n'est pas un bonus.

La 4.2 n'exige pas une liste de fonctions natives : elle exige une raison d'installer l'app plutôt que d'ouvrir un site.

Corriger un refus 4.2, étape par étape

1. Identifie la famille. Navigation web : c'est le site encapsulé. Contenu ou fonctions minimales : c'est l'app trop maigre. La 4.2.3 : une dépendance à une autre app ou un téléchargement non annoncé.
2. Change le produit, pas la formulation. Une réponse qui argumente sans rien changer n'a aucune raison de convaincre. Reconstruis en natif les écrans du geste principal, ou ajoute la profondeur qui manque.
3. Prévois un nouveau build. La cause est dans l'app : une mise à jour à distance ne suffit pas. Chaque envoi repasse par la file, voir le délai de validation App Store.
4. Écris des notes de revue qui guident. Apple demande, dans sa page sur les informations pour une revue complète, de décrire le concept, les fonctions et le public. Pour une mise à jour : ce qui a changé, et où le trouver.
5. Fais appel seulement si le reviewer a manqué quelque chose. Si ta fonction native existait déjà mais n'a pas été vue, réponds dans App Store Connect avec une courte vidéo. L'appel auprès de l'App Review Board se justifie quand ton app a été mal comprise, pas quand elle est maigre.

Le modèle de notes que j'utiliserais, en anglais, à adapter :

Hello App Review team,

Thank you for your feedback regarding Guideline 4.2.

What changed in build [X]:
- [Main feature] is now fully native: [what the user does].
- [Native feature]: [what it brings]. Where: [screen > button].
- [Second native feature]: [what it brings]. Where: [screen].
- Web content is limited to [legal pages, help].

How to test in two minutes:
1. Launch the app and [main action].
2. Turn on Airplane mode: [content] stays available.
3. Add the widget from the Home Screen: it shows [data].

Best regards,
[Your name]

N'écris que ce qui existe dans le build envoyé. Une fonction annoncée et introuvable te vaudrait un nouveau refus, au titre de la 2.1 cette fois.

La checklist 4.2 avant soumission

• Tu sais dire en une phrase ce que ton app fait qu'un site ne fait pas.
• Les écrans du geste principal sont natifs, pas des pages web.
• Chaque fonction native sert le geste principal, et le reviewer la croise en moins de deux minutes.
• L'app a du contenu réel dès le premier lancement, ou un compte de démonstration rempli.
• L'app fonctionne seule, sans autre app à installer.
• Un gros téléchargement au premier lancement annonce sa taille et demande l'accord.
• Les notes de revue décrivent le concept, le public et l'emplacement de chaque fonction.
• Si ton idée frôle la limite, tu l'as testée avant de coder, avec un MVP d'application iOS bien cadré.

Passer la 4.2 dès ta prochaine soumission

Si ton app vient d'être refusée en 4.2, le Kit Review Apple t'aide à retrouver la règle citée et ce qu'elle demande, avec les modèles de notes pour le testeur. Si tu construis encore, le parcours du Kit iOS part de la fonction principale avant la première ligne de code. Pour un regard humain, réserve une heure avec moi. La démarche complète 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 pensée pour la review dès le départ.

Personne ne peut garantir qu'Apple acceptera ton app. Je peux t'aider à lui donner une raison d'exister sur l'App Store.

Questions fréquentes

Que veut dire « Guideline 4.2 - Design - Minimum Functionality » ?

C'est l'intitulé du refus pour fonctionnalité minimale. Apple juge que ton app ressemble trop à un site web, ou qu'elle offre trop peu de contenu ou de fonctions. Le même intitulé peut viser une sous-règle : « Guideline 4.2.2 » pour une app vitrine ou une liste de liens, 4.2.3 pour une app qui dépend d'une autre app.

Une application en WebView est-elle toujours refusée ?

Non. La règle vise le site web remis dans une app, pas la technologie. Le reviewer juge l'expérience principale : si ses écrans sont des pages web qui font la même chose que Safari, le risque est élevé. Une page d'aide ouverte dans le navigateur n'est pas le sujet.

Ajouter des notifications push suffit-il à passer la 4.2 ?

Non. Dans un message de refus publié sur ses forums, Apple écrit que les notifications, la localisation et le partage ne suffisent pas à rendre l'expérience assez riche. Une notification compte quand elle sert la fonction principale, comme une alarme ou un rappel choisi par la personne.

Quelle différence entre la guideline 4.2 et la 4.3 ?

La 4.2 juge ton app seule : apporte-t-elle assez par rapport à un site web ? La 4.3 la compare aux autres : est-elle une copie, une variante ou une app de plus dans une catégorie saturée ? Une même app peut prendre les deux, mais elles ne se corrigent pas de la même manière.

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

Presque toujours, puisque la cause est dans l'app elle‑même. Seule exception : le reviewer n'a pas trouvé une fonction qui existait déjà. Dans ce cas, réponds dans App Store Connect avec des notes précises et une courte vidéo, sans changer le build.