Devoria
Guideline 4.0 Design: app rebutjada per la interfície
Per Mehdi Azizi
Publicat el , 9 min
Guideline 4.0 Design: Apple rebutja una interfície difícil d'usar, sovint a l'iPad. Prova cada pantalla a l'iPhone SE i l'iPad, corregeix i respon.
"Guideline 4.0 - Design" no és una norma numerada com les altres: és la introducció de la secció Design de les normes d'Apple, i la citen quan la teva interfície sembla per sota del nivell esperat. Els rebuigs publicats s'assemblen: pantalles atapeïdes a l'iPad, text difícil de llegir, inici de sessió enviat a Safari, Sign in with Apple mal integrat. La correcció gairebé sempre comença en el dispositiu que cita el missatge, pantalla per pantalla.
Publico les meves pròpies apps iOS amb Expo: Solys, TradaZen i Nolera estan configurades només per a iPhone, i tot i així el revisor va provar Solys i Nolera en un iPad. Aquesta guia es basa en el text d'Apple, en rebuigs 4.0 publicats per altres desenvolupadors i en la graella visual que aplico abans de cada enviament. Per a la visió de conjunt dels motius, llegeix per què Apple rebutja una app.
Què cobreix la guideline 4.0 Design?
La secció 4 de les App Review Guidelines s'obre amb un paràgraf sense número: "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." Hi afegeix que el disseny és cosa teva, però que el que ve després fixa uns "minimum standards for approval". També avisa que una app que es degrada després de ser aprovada pot ser retirada.
En resum: Apple espera una app senzilla, polida i fàcil d'usar, i la 4.0 serveix quan el problema no encaixa en cap subnorma concreta. El text no dona criteris amb xifres. La referència pràctica són les Human Interface Guidelines, les normes de disseny d'Apple.
Els rebuigs 4.0 més freqüents
Aquests són els quatre casos que he trobat en missatges publicats als fòrums d'Apple, amb la fórmula citada.
| Cas | Fórmula d'Apple | Correcció |
|---|---|---|
| Pantalles atapeïdes a l'iPad | "crowded" | Disseny fluid |
| Text il·legible | "hard to read type" | Mides HIG |
| Inici de sessió a Safari | "taken to Safari" | Inici de sessió dins l'app |
| Sign in with Apple | Nom demanat de nou | Nom ja proporcionat |
Pantalles atapeïdes o tallades a l'iPad
El missatge tipus, publicat el setembre de 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." Després precisava que l'app només feia servir una part de la pantalla (fil del fòrum).
La causa és la norma 2.4.1: "iPhone apps should run on iPad whenever possible." Amb Expo, l'opció ios.supportsTablet val false per defecte, segons la configuració d'app d'Expo. Llavors la teva app d'iPhone funciona a l'iPad en mode de compatibilitat, en una finestra amb format d'iPhone. Configurar l'app només per a iPhone no la protegeix d'una prova a l'iPad. Va ser en un iPad Air on la demo de Solys es va tornar impossible de guanyar, un cas que detallo a la guia de la guideline 2.1.
Dues sortides. O dones suport de veritat a l'iPad, amb un disseny que s'adapta a l'espai disponible. Les normes de disseny d'Apple demanen decidir la disposició segons les classes de mida, no segons el model de dispositiu. O et quedes a l'iPhone, i cada pantalla ha de cabre a la finestra de compatibilitat.
Text difícil de llegir
El missatge, publicat el gener de 2025: "Your app included hard to read type or typography." Apple hi recorda que els usuaris esperen apps "simple, refined, and easy to use" (fil del fòrum).
Les normes de tipografia d'Apple donen referències per a iOS: 17 punts per defecte, 11 punts com a mínim. Les normes d'accessibilitat demanen un contrast d'almenys 4,5 a 1 per a un text de fins a 17 punts, i zones tàctils de 44 per 44 punts per defecte.
Un parany si redueixes les fonts a les pantalles petites, com faig jo per mantenir els mateixos salts de línia a tot arreu: comprova que el teu text més petit, reduït a l'iPhone SE, continua tenint almenys 11 punts.
Inici de sessió enviat a Safari
El missatge, publicat al fòrum 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 demana permetre el registre i l'inici de sessió dins l'app, i recomana una vista de Safari integrada.
Amb Expo, expo-web-browser cobreix les dues necessitats sense sortir de l'app: openAuthSessionAsync obre una sessió d'autenticació en una finestra modal, i openBrowserAsync mostra una pàgina en una vista de Safari integrada. En canvi, obrir l'inici de sessió amb Linking.openURL envia l'usuari a l'app Safari. Quins mètodes d'inici de sessió has d'oferir és una altra qüestió, que depèn de la norma 4.8.
Sign in with Apple mal integrat
El missatge, publicat el maig de 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 del fòrum).
La documentació d'expo-apple-authentication explica el parany: el nom i el correu només es proporcionen el primer cop que l'usuari inicia sessió. Desa'ls de seguida, si no, tindràs la temptació de tornar-los a demanar. Fes servir també el botó que dona la biblioteca: el color es tria amb buttonStyle i les cantonades amb cornerRadius, mai amb style.
4.0, 4.2, 4.3: tres rebuigs de disseny que no has de confondre
| Norma | Què es jutja | Correcció |
|---|---|---|
| 4.0 | La interfície | Corregir les pantalles |
| 4.2 | La utilitat de l'app | Afegir contingut natiu |
| 4.3 | La semblança | Canviar de concepte |
La 4.2, Minimum Functionality, demana funcions, contingut i una interfície que portin l'app "beyond a repackaged website". La frontera amb la 4.0 és fina: un web empaquetat en una app es pot endur les dues. Si a la teva app li falta substància, retocar les pantalles no n'hi haurà prou.
La 4.3 apunta a les còpies i a les categories saturades: n'he detallat els dos apartats a la guia de la guideline 4.3 Design Spam. Una interfície polida no salva una app que s'assembla a mil més.
La graella visual abans d'enviar
És el que afegeixo a cada enviament. A les meves apps, cada pantalla està dissenyada per a l'iPhone més gran i després es redueix amb una sola escala als més petits: mateixes proporcions, mateixos salts de línia. Després comparo els resultats un al costat de l'altre: iPhone SE, iPhone estàndard, l'iPhone més gran i un iPad per al mode de compatibilitat.
| Control | Dispositiu | Què ha d'aguantar |
|---|---|---|
| Primer llançament | iPhone SE | Res tallat |
| Onboarding complet | iPad | Cada botó accessible |
| Teclat obert | iPhone SE | Camp i botó visibles |
| Text ampliat | iPhone estàndard | Cap text truncat |
| Mode fosc | Tots | Text llegible a tot arreu |
| Zones segures | El més gran | Res sota la Dynamic Island |
| Paywall | iPhone SE | Preus i enllaços visibles |
| Inici de sessió | iPad | Es queda dins l'app |
Tres aclariments:
- Text ampliat. Les normes de tipografia d'Apple proposen una prova senzilla: activar les mides de text més grans a Settings, Accessibility, Display & Text Size, i comprovar que tot continua sent llegible.
- Mode fosc. Les normes d'Apple sobre el mode fosc demanen que l'app sigui llegible en les dues aparences. Expo aplica
lightper defecte si no configuresuserInterfaceStyle. Solys segueix la configuració del telèfon, TradaZen es queda en fosc i Nolera en clar: en els tres casos, provo l'aparença que es mostra. - Zones segures. El contingut no passa ni sota la Dynamic Island ni sota l'indicador d'inici. Expo detalla el mètode a la seva guia de zones segures.
Al Mac, el simulador es configura per línia d'ordres, així que la graella es repeteix ràpid:
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
En un telèfon real, faig la mateixa volta amb un build de TestFlight. Metodologia: aquesta graella és meva, construïda a partir dels rebuigs que han rebut les meves apps, no és una llista d'Apple. Redueix les sorpreses, però no garanteix l'aprovació.
Com respondre a un rebuig 4.0?
- Identifica el dispositiu i la versió que cita el missatge, i obre el mateix model al simulador.
- Corregeix tots els casos. El missatge tipus demana "address all instances" del problema, no només la pantalla de la captura.
- Envia un build nou: el revisor prova el codi inclòs a l'app.
- Respon amb captures fetes en el mateix dispositiu, responent al missatge d'App Review.
- Apel·la només si n'estàs segur: Apple permet recórrer a l'App Review Board, amb una sola apel·lació per enviament rebutjat.
La plantilla que faria servir, per adaptar:
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,
Preparar l'enviament sense rebuigs de disseny
El Review Kit reuneix la meva checklist abans d'enviar, que cobreix entre altres la norma 2.4.1 sobre l'iPad, i skills de Claude Code que revisen el teu projecte. Si vols una mirada humana, reserva una hora amb mi: obrim les teves pantalles en diverses mides, per videotrucada. El procés complet després d'un rebuig és a la pàgina app rebutjada per Apple.
Prepares el teu primer llançament? Fes el diagnòstic gratuït: t'ordena els passos i t'envia la meva checklist antirebuig d'Apple.
Preguntes freqüents
Què vol dir "Guideline 4.0 - Design" en un missatge de rebuig?
Apple considera que la teva interfície està per sota del nivell esperat, sense apuntar a cap subnorma concreta: pantalles atapeïdes, text difícil de llegir, un flux d'inici de sessió que consideren dolent. El missatge normalment cita el dispositiu utilitzat i sovint adjunta una captura.
La meva app està configurada només per a iPhone: per què Apple la prova a l'iPad?
Perquè la norma 2.4.1 vol que les apps d'iPhone funcionin a l'iPad sempre que sigui possible. La teva app s'hi obre en mode de compatibilitat, en una finestra amb format d'iPhone, i cada pantalla hi ha de continuar sent usable.
Cal un build nou després d'un rebuig 4.0?
Sí, en la majoria de casos. El revisor prova el codi inclòs a l'app en el primer llançament, i una correcció enviada a distància se li pot escapar. És el que explico a la guia de la guideline 2.1.
El mode fosc és obligatori per ser acceptat?
El text de les normes de revisió no l'imposa. Les normes de disseny recorden que els usuaris esperen que les apps segueixin la seva configuració. Si forces el clar o el fosc, com permet Expo, prova aquesta aparença. Si segueixes la configuració del telèfon, prova totes dues.
Es pot apel·lar un rebuig 4.0?
Sí, davant l'App Review Board, si creus que la teva app compleix les normes. Apple demana motius concrets, una sola apel·lació per enviament rebutjat, i que primer responguis a les peticions d'informació.
