Guideline 4.0 Design : app refusée pour son interface

« Guideline 4.0 - Design » n'est pas une règle numérotée comme les autres : c'est l'introduction de la section Design des règles d'Apple, citée quand ton interface paraît en dessous du niveau attendu. Les refus publiés se ressemblent : écrans tassés sur iPad, texte difficile à lire, connexion envoyée vers Safari, Sign in with Apple mal intégré. La correction commence presque toujours sur l'appareil que cite le message, écran par écran.

Je publie mes propres apps iOS avec Expo : Solys, TradaZen et Nolera sont réglées pour l'iPhone seul, et le reviewer a pourtant testé Solys et Nolera sur iPad. Ce guide s'appuie sur le texte d'Apple, sur des refus 4.0 publiés par d'autres développeurs et sur la grille visuelle que j'applique avant chaque envoi. Pour la vue d'ensemble des motifs, lis pourquoi Apple refuse une app.

Que couvre la guideline 4.0 Design ?

La section 4 des App Review Guidelines s'ouvre sur un paragraphe sans numéro : « Apple customers place a high value on products that are simple, refined, innovative, and easy to use, and that's what we want to see on the App Store. » Il ajoute que le design t'appartient, mais que la suite fixe des « minimum standards for approval ». Il prévient aussi qu'une app qui se dégrade après sa validation peut être retirée.

En clair : Apple attend une app simple, soignée et facile à utiliser, et la 4.0 sert quand le problème ne relève d'aucune sous-règle précise. Le texte ne donne pas de critères chiffrés. La référence pratique, ce sont les Human Interface Guidelines, les règles de design d'Apple.

Les refus 4.0 les plus fréquents

Voici les quatre cas que j'ai retrouvés dans des messages publiés sur les forums d'Apple, avec la formule citée.

Cas	Formule d'Apple	Correctif
Écrans tassés sur iPad	« crowded »	Mise en page fluide
Texte illisible	« hard to read type »	Tailles HIG
Connexion dans Safari	« taken to Safari »	Connexion dans l'app
Sign in with Apple	Nom redemandé	Nom déjà fourni

Écrans tassés ou coupés sur iPad

Le message type, publié en septembre 2025 : « Parts of the app's user interface were still crowded, laid out, or displayed in a way that made it difficult to use the app when reviewed on iPad Air (5th generation) running iPadOS 26.0. » La suite précisait que l'app n'utilisait qu'une partie de l'écran (fil du forum).

La cause tient à la règle 2.4.1 : « iPhone apps should run on iPad whenever possible. » Avec Expo, l'option ios.supportsTablet vaut false par défaut, selon la configuration d'app d'Expo. Ton app iPhone tourne alors sur iPad en mode compatibilité, dans une fenêtre au format iPhone. Régler l'app sur iPhone seul ne la met pas à l'abri d'un test sur iPad. C'est sur un iPad Air que la démo de Solys est devenue impossible à gagner, un cas détaillé dans le guide de la guideline 2.1.

Deux sorties. Soit tu prends vraiment en charge l'iPad, avec une mise en page qui suit la place disponible. Les règles de design d'Apple demandent de décider la disposition selon les classes de taille, pas selon le modèle d'appareil. Soit tu restes sur l'iPhone, et chaque écran doit tenir dans la fenêtre de compatibilité.

Texte difficile à lire

Le message, publié en janvier 2025 : « Your app included hard to read type or typography. » Apple y rappelle que les utilisateurs attendent des apps « simple, refined, and easy to use » (fil du forum).

Les règles de typographie d'Apple donnent des repères sur iOS : 17 points par défaut, 11 points au minimum. Les règles d'accessibilité demandent un contraste d'au moins 4,5 pour 1 pour un texte jusqu'à 17 points, et des zones de toucher de 44 sur 44 points par défaut.

Un piège si tu réduis les polices sur les petits écrans, comme je le fais pour garder les mêmes retours à la ligne partout : vérifie que ton plus petit texte, réduit sur iPhone SE, garde au moins 11 points.

Connexion envoyée vers Safari

Le message, publié sur le forum d'Apple : « We noticed that the user is taken to Safari to sign in or register for an account, which provides a poor user experience. » Apple demande de permettre l'inscription et la connexion dans l'app, et recommande une vue Safari intégrée.

Avec Expo, expo-web-browser couvre les deux besoins sans quitter l'app : openAuthSessionAsync ouvre une session d'authentification dans une fenêtre modale, et openBrowserAsync affiche une page dans une vue Safari intégrée. Ouvrir la connexion avec Linking.openURL envoie au contraire vers l'app Safari. Le choix des moyens de connexion à proposer, lui, relève d'une autre règle, la 4.8.

Sign in with Apple mal intégré

Le message, publié en mai 2024 : « Your app requires users to provide their name after using Sign in with Apple. This information is already provided by the Authentication Services framework. » (fil du forum).

La documentation d'expo-apple-authentication explique le piège : le nom et l'e-mail ne sont fournis qu'à la première connexion. Enregistre-les tout de suite, sinon tu seras tenté de les redemander. Utilise aussi le bouton fourni par la bibliothèque : sa couleur se choisit avec buttonStyle et ses coins avec cornerRadius, jamais par style.

4.0, 4.2, 4.3 : trois refus de design à ne pas confondre

Règle	Ce qui est jugé	Correctif
4.0	L'interface	Corriger les écrans
4.2	L'utilité de l'app	Ajouter du fond natif
4.3	La ressemblance	Changer de concept

La 4.2, Minimum Functionality, demande des fonctions, du contenu et une interface qui élèvent l'app « beyond a repackaged website ». La frontière avec la 4.0 est fine : un site emballé dans une app peut prendre les deux. Si ton app manque de fond, retoucher les écrans ne suffira pas.

La 4.3 vise les copies et les catégories saturées : j'ai détaillé ses deux alinéas dans le guide de la guideline 4.3 Design Spam. Une interface soignée ne sauve pas une app qui ressemble à mille autres.

La grille visuelle avant soumission

C'est l'élément que j'ajoute à chaque envoi. Sur mes apps, chaque écran est dessiné pour le plus grand iPhone, puis réduit d'une seule échelle sur les plus petits : mêmes proportions, mêmes retours à la ligne. Je compare ensuite les rendus côte à côte : iPhone SE, iPhone standard, plus grand iPhone, et un iPad pour le mode compatibilité.

Contrôle	Appareil	Ce qui doit tenir
Premier lancement	iPhone SE	Rien de coupé
Onboarding complet	iPad	Chaque bouton accessible
Clavier ouvert	iPhone SE	Champ et bouton visibles
Texte agrandi	iPhone standard	Aucun texte tronqué
Mode sombre	Tous	Texte lisible partout
Zones sûres	Plus grand	Rien sous la Dynamic Island
Paywall	iPhone SE	Prix et liens visibles
Connexion	iPad	Elle reste dans l'app

Trois précisions :

• Texte agrandi. Les règles de typographie d'Apple proposent un test simple : activer les plus grandes tailles de texte dans Réglages, Accessibilité, Affichage et taille du texte, puis vérifier que tout reste lisible.
• Mode sombre. Les règles d'Apple sur le mode sombre demandent que l'app reste lisible dans les deux apparences. Expo applique light par défaut si tu ne règles pas userInterfaceStyle. Solys suit le réglage du téléphone, TradaZen reste en sombre, Nolera en clair : dans les trois cas, je teste l'apparence affichée.
• Zones sûres. Le contenu ne passe ni sous la Dynamic Island ni sous l'indicateur d'accueil. Expo détaille la méthode dans son guide des zones sûres.

Sur Mac, le simulateur se règle en ligne de commande, ce qui rend la grille rapide à rejouer :

xcrun simctl ui booted appearance dark
xcrun simctl ui booted content_size accessibility-extra-extra-extra-large
xcrun simctl io booted screenshot ecran-se-sombre.png

Sur un vrai téléphone, je refais le même tour avec un build TestFlight. Méthodologie : cette grille est la mienne, construite sur les refus pris par mes apps, pas une liste fournie par Apple. Elle réduit les surprises sans garantir l'acceptation.

Comment répondre à un refus 4.0 ?

1. Repère l'appareil et la version cités dans le message, puis ouvre le même modèle dans le simulateur.
2. Corrige toutes les occurrences. Le message type demande de « address all instances » du problème, pas seulement l'écran de la capture.
3. Envoie un nouveau build : le reviewer teste le code embarqué.
4. Réponds avec des captures prises sur le même appareil, en répondant au message d'App Review.
5. Fais appel seulement si tu es sûr : Apple permet de saisir l'App Review Board, avec un seul appel par soumission refusée.

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

Hello,

Thank you for your feedback regarding Guideline 4.0.

We reproduced the issue on [device] running [OS version].

Changes in build [X]:
- [Screen]: [what was crowded or hard to read], now [fix].
- [Screen]: [fix].

We also checked every screen on iPhone SE, a standard
iPhone, the largest iPhone and iPad, with larger text
sizes and Dark Mode.

Attached: screenshots of the updated screens on [device].

Best regards,

Préparer ton envoi sans refus de design

Le Kit Review Apple réunit ma checklist avant l'envoi, qui couvre notamment la règle 2.4.1 sur l'iPad, et des skills Claude Code qui relisent ton projet. Pour un regard humain, réserve une heure avec moi : on ouvre tes écrans sur plusieurs tailles, en visio. La démarche complète après un refus est sur la page application refusée par Apple.

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.

Questions fréquentes

Que veut dire « Guideline 4.0 - Design » dans un message de refus ?

Apple juge ton interface en dessous du niveau attendu, sans viser une sous-règle précise : écrans tassés, texte difficile à lire, parcours de connexion jugé mauvais. Le message cite en général l'appareil utilisé et joint souvent une capture.

Mon app est réglée pour l'iPhone seul : pourquoi Apple la teste sur iPad ?

Parce que la règle 2.4.1 veut que les apps iPhone tournent sur iPad dès que possible. Ton app s'y ouvre en mode compatibilité, dans une fenêtre au format iPhone, et chaque écran doit y rester utilisable.

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

Oui, dans la plupart des cas. Le reviewer teste le code embarqué au premier lancement, et un correctif livré à distance peut lui échapper. C'est ce que j'explique dans le guide de la guideline 2.1.

Le mode sombre est-il obligatoire pour être accepté ?

Le texte des règles de revue ne l'impose pas. Les règles de design rappellent que les utilisateurs s'attendent à ce que les apps suivent leur réglage. Si tu forces le clair ou le sombre, comme Expo le permet, teste cette apparence. Si tu suis le réglage du téléphone, teste les deux.

Peut-on faire appel d'un refus 4.0 ?

Oui, auprès de l'App Review Board, si tu penses que ton app respecte les règles. Apple demande des raisons précises, un seul appel par soumission refusée, et de répondre d'abord aux demandes d'information.