# Guideline 4.0 Design : app refusée pour son interface > Guideline 4.0 Design : Apple refuse une interface jugée difficile à utiliser, souvent sur iPad. Teste chaque écran sur iPhone SE et iPad, corrige, puis réponds. Page originale : [Guideline 4.0 Design : app refusée pour son interface](https://devoria.fr/blog/guideline-4-0-design) Auteur : [Mehdi Azizi](https://devoria.fr/mehdi-azizi) Publication : 2026-11-04 Dernière révision du contenu : 2026-11-04 « 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](https://devoria.fr/blog/pourquoi-apple-refuse-votre-app). ## Que couvre la guideline 4.0 Design ? La section 4 des [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#design) 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](https://developer.apple.com/design/human-interface-guidelines/layout), 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](https://developer.apple.com/forums/thread/800657)). 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](https://docs.expo.dev/versions/latest/config/app/). 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](https://devoria.fr/blog/guideline-2-1-app-store-refus). 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](https://developer.apple.com/forums/thread/772671)). Les [règles de typographie d'Apple](https://developer.apple.com/design/human-interface-guidelines/typography) donnent des repères sur iOS : 17 points par défaut, 11 points au minimum. Les [règles d'accessibilité](https://developer.apple.com/design/human-interface-guidelines/accessibility) 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](https://developer.apple.com/forums/thread/126333) : « 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](https://docs.expo.dev/versions/latest/sdk/webbrowser/) 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](https://developer.apple.com/forums/thread/751115)). La documentation d'[expo-apple-authentication](https://docs.expo.dev/versions/latest/sdk/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](https://devoria.fr/blog/guideline-4-2-fonctionnalite-minimale), 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](https://devoria.fr/blog/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](https://developer.apple.com/design/human-interface-guidelines/dark-mode) 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](https://docs.expo.dev/develop/user-interface/safe-areas/). Sur Mac, le simulateur se règle en ligne de commande, ce qui rend la grille rapide à rejouer : ```bash 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](https://devoria.fr/blog/testflight-tester-son-app-iphone). 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](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/reply-to-app-review-messages/). 5. **Fais appel seulement si tu es sûr** : Apple permet de [saisir l'App Review Board](https://developer.apple.com/distribute/app-review/), avec un seul appel par soumission refusée. Le modèle que j'utiliserais, à adapter : ```text 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](https://devoria.fr/kits/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](https://devoria.fr/coaching) : 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](https://devoria.fr/expertise/application-refusee-par-apple). Tu prépares ta première sortie ? [Fais ton diagnostic gratuit](https://devoria.fr/diagnostic) : 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. ## Ton projet [Kit Review](https://devoria.fr/kits/review-apple) : Tout ce que je vérifie avant d'envoyer une app à Apple, la même vérification pour Google Play, et trois skills qui font la relecture avec Claude Code. 49 €, paiement unique. Inclus : La checklist avant l'envoi ; Les refus que j'ai pris, et ce que j'ai corrigé ; Les notes pour le testeur ; Les skills de vérification. Prérequis : une app iPhone ou Android presque prête, et Claude Code ou Cursor. Téléchargement immédiat après le paiement. [Kit iOS & Android Devoria](https://devoria.fr/kits/ios) : Le code de départ de mes apps, le parcours jusqu'à l'App Store et Google Play avec les messages à donner à Claude, et tous les kits. Claude part d'une app qui tourne déjà. 99 €, paiement unique. Inclus : Le code de départ de ton app ; Les styles visuels ; Le parcours pas à pas ; Kit Review ; Kit Captures ; Kit ASO ; Mises à jour à vie ; Bonus : la séance 1:1 à moitié prix. Prérequis : pour l'iPhone, un Mac avec Xcode 26 ou plus et un compte Apple Developer (99 $ par an) pour publier. Pour Android, Android Studio sur un Mac, un PC Windows ou Linux, et un compte Google Play Console (25 $, une fois). Et Claude Code (abonnement payant) ou Cursor. Téléchargement immédiat après le paiement. [Diagnostic gratuit](https://devoria.fr/diagnostic) : quelques questions sur ton projet. Il dit ce qui te bloque vraiment, l'ordre des quatre étapes et le kit qui correspond. En laissant ton e-mail, tu reçois la checklist anti-refus Apple : les points vérifiés avant chaque envoi, tirés des refus reçus par les apps du studio. [Une heure avec moi](https://devoria.fr/coaching) : On regarde ton app ou ton projet Claude, écran partagé : ce qui bloque, ce que je change en premier, et dans quel ordre. 100 € la séance d'une heure, en visio, paiement en une fois. Sujets : L'audit de ton app ; Ton travail avec Claude ; Ta fiche et ton paywall ; Un refus d'Apple.