Devoria
Guideline 4.0 Design: app rechazada por su interfaz
Por Mehdi Azizi
Publicado el , 9 min
Guideline 4.0 Design: Apple rechaza una interfaz difícil de usar, a menudo en iPad. Prueba cada pantalla en iPhone SE y iPad, corrige y luego responde.
"Guideline 4.0 - Design" no es una regla numerada como las demás: es la introducción de la sección Design de las reglas de Apple, y se cita cuando tu interfaz parece estar por debajo del nivel esperado. Los rechazos publicados se parecen entre sí: pantallas amontonadas en iPad, texto difícil de leer, inicio de sesión que manda a Safari, Sign in with Apple mal integrado. La corrección empieza casi siempre en el dispositivo que menciona el mensaje, pantalla por pantalla.
Publico mis propias apps iOS con Expo: Solys, TradaZen y Nolera están configuradas solo para iPhone y, aun así, el revisor probó Solys y Nolera en iPad. Esta guía se basa en el texto de Apple, en rechazos 4.0 publicados por otros desarrolladores y en la checklist visual que aplico antes de cada envío. Para ver el panorama general de los motivos, lee por qué Apple rechaza una app.
¿Qué cubre la guideline 4.0 Design?
La sección 4 de las App Review Guidelines se abre con un párrafo sin 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." Añade que el diseño es cosa tuya, pero que lo que sigue fija unos "minimum standards for approval". También advierte que una app que se degrada después de su aprobación puede ser retirada.
En pocas palabras: Apple espera una app simple, cuidada y fácil de usar, y la 4.0 se aplica cuando el problema no encaja en ninguna subregla concreta. El texto no da criterios cuantificados. La referencia práctica son las Human Interface Guidelines, las reglas de diseño de Apple.
Los rechazos 4.0 más frecuentes
Estos son los cuatro casos que encontré en mensajes publicados en los foros de Apple, con la frase citada.
| Caso | Frase de Apple | Solución |
|---|---|---|
| Pantallas amontonadas en iPad | "crowded" | Diseño fluido |
| Texto ilegible | "hard to read type" | Tamaños HIG |
| Inicio de sesión en Safari | "taken to Safari" | Inicio de sesión en la app |
| Sign in with Apple | Nombre pedido otra vez | Nombre ya proporcionado |
Pantallas amontonadas o cortadas en iPad
El mensaje típico, publicado en septiembre 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." Después precisaba que la app solo usaba una parte de la pantalla (hilo del foro).
La causa está en la regla 2.4.1: "iPhone apps should run on iPad whenever possible." Con Expo, la opción ios.supportsTablet vale false por defecto, según la configuración de app de Expo. Tu app de iPhone corre entonces en iPad en modo compatibilidad, en una ventana con formato de iPhone. Configurar la app solo para iPhone no la protege de una prueba en iPad. Fue en un iPad Air donde la demo de Solys se volvió imposible de ganar, un caso que detallo en la guía de la guideline 2.1.
Hay dos salidas. O soportas el iPad de verdad, con un diseño que se adapte al espacio disponible. Las reglas de diseño de Apple piden decidir la disposición según las clases de tamaño, no según el modelo de dispositivo. O te quedas en iPhone, y cada pantalla tiene que caber en la ventana de compatibilidad.
Texto difícil de leer
El mensaje, publicado en enero de 2025: "Your app included hard to read type or typography." Apple recuerda ahí que los usuarios esperan apps "simple, refined, and easy to use" (hilo del foro).
Las reglas de tipografía de Apple dan referencias para iOS: 17 puntos por defecto, 11 puntos como mínimo. Las reglas de accesibilidad piden un contraste de al menos 4,5 a 1 para texto de hasta 17 puntos, y áreas táctiles de 44 por 44 puntos por defecto.
Una trampa si reduces las fuentes en pantallas pequeñas, como hago yo para mantener los mismos saltos de línea en todas partes: verifica que tu texto más pequeño, reducido en iPhone SE, siga teniendo al menos 11 puntos.
Inicio de sesión que manda a Safari
El mensaje, publicado en el foro de 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 pide permitir el registro y el inicio de sesión dentro de la app, y recomienda una vista de Safari integrada.
Con Expo, expo-web-browser cubre ambas necesidades sin salir de la app: openAuthSessionAsync abre una sesión de autenticación en una ventana modal, y openBrowserAsync muestra una página en una vista de Safari integrada. En cambio, abrir el inicio de sesión con Linking.openURL manda a la app Safari. La elección de los métodos de inicio de sesión que ofreces depende de otra regla, la 4.8.
Sign in with Apple mal integrado
El mensaje, publicado en mayo 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." (hilo del foro).
La documentación de expo-apple-authentication explica la trampa: el nombre y el correo solo se entregan en el primer inicio de sesión. Guárdalos de inmediato, o te verás tentado a pedirlos otra vez. Usa también el botón que trae la biblioteca: su color se elige con buttonStyle y sus esquinas con cornerRadius, nunca con style.
4.0, 4.2, 4.3: tres rechazos de diseño que no hay que confundir
| Regla | Lo que se evalúa | Solución |
|---|---|---|
| 4.0 | La interfaz | Corregir las pantallas |
| 4.2 | La utilidad de la app | Añadir contenido nativo |
| 4.3 | El parecido | Cambiar de concepto |
La 4.2, Minimum Functionality, exige funciones, contenido y una interfaz que eleven la app "beyond a repackaged website". La frontera con la 4.0 es delgada: un sitio web empaquetado en una app puede recibir los dos. Si a tu app le falta sustancia, retocar las pantallas no bastará.
La 4.3 apunta a las copias y a las categorías saturadas: detallé sus dos apartados en la guía de la guideline 4.3 Design Spam. Una interfaz cuidada no salva a una app que se parece a otras mil.
La checklist visual antes del envío
Es lo que añado en cada envío. En mis apps, cada pantalla está diseñada para el iPhone más grande y luego se reduce con una sola escala en los más pequeños: mismas proporciones, mismos saltos de línea. Después comparo los resultados lado a lado: iPhone SE, iPhone estándar, el iPhone más grande y un iPad para el modo compatibilidad.
| Control | Dispositivo | Lo que debe aguantar |
|---|---|---|
| Primer arranque | iPhone SE | Nada cortado |
| Onboarding completo | iPad | Cada botón accesible |
| Teclado abierto | iPhone SE | Campo y botón visibles |
| Texto agrandado | iPhone estándar | Ningún texto truncado |
| Modo oscuro | Todos | Texto legible en todas partes |
| Áreas seguras | El más grande | Nada debajo de la Dynamic Island |
| Paywall | iPhone SE | Precios y enlaces visibles |
| Inicio de sesión | iPad | Se queda dentro de la app |
Tres aclaraciones:
- Texto agrandado. Las reglas de tipografía de Apple proponen una prueba sencilla: activar los tamaños de texto más grandes en Settings, Accessibility, Display & Text Size, y comprobar que todo siga legible.
- Modo oscuro. Las reglas de Apple sobre el modo oscuro piden que la app siga siendo legible en ambas apariencias. Expo aplica
lightpor defecto si no configurasuserInterfaceStyle. Solys sigue el ajuste del teléfono, TradaZen se queda en oscuro y Nolera en claro: en los tres casos, pruebo la apariencia que se muestra. - Áreas seguras. El contenido no pasa ni debajo de la Dynamic Island ni debajo del indicador de inicio. Expo detalla el método en su guía de áreas seguras.
En Mac, el simulador se configura por línea de comandos, lo que hace que la checklist sea rápida de repetir:
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éfono real, repito el mismo recorrido con un build de TestFlight. Metodología: esta checklist es mía, construida a partir de los rechazos que recibieron mis apps, no una lista proporcionada por Apple. Reduce las sorpresas sin garantizar la aprobación.
¿Cómo responder a un rechazo 4.0?
- Identifica el dispositivo y la versión que cita el mensaje, y abre el mismo modelo en el simulador.
- Corrige todas las ocurrencias. El mensaje típico pide "address all instances" del problema, no solo la pantalla de la captura.
- Envía un nuevo build: el revisor prueba el código incluido en la app.
- Responde con capturas tomadas en el mismo dispositivo, respondiendo al mensaje de App Review.
- Apela solo si estás seguro: Apple permite acudir al App Review Board, con una sola apelación por envío rechazado.
La plantilla que yo usaría, para 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,
Prepara tu envío sin rechazos de diseño
El Review Kit reúne mi checklist previa al envío, que cubre en particular la regla 2.4.1 sobre el iPad, y skills de Claude Code que revisan tu proyecto. Si quieres una mirada humana, reserva una hora conmigo: abrimos tus pantallas en varios tamaños, por videollamada. El proceso completo después de un rechazo está en la página app rechazada por Apple.
¿Estás preparando tu primer lanzamiento? Haz tu diagnóstico gratuito: pone los pasos en orden y te envía mi checklist anti-rechazo de Apple.
Preguntas frecuentes
¿Qué significa "Guideline 4.0 - Design" en un mensaje de rechazo?
Apple considera que tu interfaz está por debajo del nivel esperado, sin apuntar a una subregla concreta: pantallas amontonadas, texto difícil de leer, flujo de inicio de sesión considerado malo. El mensaje suele citar el dispositivo usado y a menudo adjunta una captura.
Mi app está configurada solo para iPhone: ¿por qué Apple la prueba en iPad?
Porque la regla 2.4.1 pide que las apps de iPhone funcionen en iPad siempre que sea posible. Tu app se abre ahí en modo compatibilidad, en una ventana con formato de iPhone, y cada pantalla tiene que seguir siendo usable.
¿Hace falta un nuevo build después de un rechazo 4.0?
Sí, en la mayoría de los casos. El revisor prueba el código incluido en el primer arranque, y una corrección enviada a distancia puede pasarle desapercibida. Es lo que explico en la guía de la guideline 2.1.
¿El modo oscuro es obligatorio para que te aprueben?
El texto de las reglas de revisión no lo exige. Las reglas de diseño recuerdan que los usuarios esperan que las apps sigan su ajuste. Si fuerzas el modo claro o el oscuro, como permite Expo, prueba esa apariencia. Si sigues el ajuste del teléfono, prueba las dos.
¿Se puede apelar un rechazo 4.0?
Sí, ante el App Review Board, si crees que tu app cumple las reglas. Apple pide razones precisas, una sola apelación por envío rechazado y que respondas primero a las solicitudes de información.
