¿Apple rechazó tu app por la guía 4.2? Cómo solucionarlo

Convertiste tu web en una app, la enviaste y llegó el correo: Guideline 4.2 – Design – Minimum Functionality. Es el rechazo más habitual para las apps basadas en web, y el mensaje casi nunca dice qué cambiar exactamente.

Esta guía explica qué dice realmente la directriz, qué detectan los revisores en una web empaquetada, qué cambios marcan la diferencia y cómo volver a enviar la app. También cubre dos reglas que casi nadie menciona —la 4.2.6 y la 4.3(a)— y que importan en cuanto usas un creador de apps.

Las citas proceden de las App Review Guidelines de Apple, actualizadas el 8 de junio de 2026, en su versión original en inglés (Apple también ofrece una versión en español). Nadie puede garantizar una aprobación: App Review decide caso por caso. Lo que sí puedes hacer es eliminar los motivos de rechazo.

Qué dice realmente la guía 4.2

El núcleo de la regla es un párrafo:

"Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or "app-like," it doesn't belong on the App Store."

Es decir: tu app debe ofrecer funciones, contenido e interfaz que vayan más allá de una web reempaquetada. Y una subregla que nombra los problemas típicos de las web apps:

4.2.2 "Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links."

De ahí salen dos ideas:

1. Usar tecnología web no está prohibido. Muchas apps aprobadas muestran contenido web. La cuestión es si el resultado se comporta como una app o como un navegador con icono.
2. El listón es subjetivo. "App-like" lo valora una persona que usa tu app unos minutos. Tu objetivo es que esos minutos se sientan como una app.

Qué detectan los revisores en una web empaquetada

Estas son las señales que suelen acabar en un rechazo por la 4.2:

• Comportamiento de navegador. Zoom con dos dedos sobre un diseño de escritorio, enlaces que abren Safari, un "página no encontrada" del servidor, saltos visibles al hacer scroll.
• Solo navegación web. Un menú hamburguesa y un pie de página lleno de enlaces en lugar de una navegación de app siempre accesible.
• Sin estado sin conexión. En modo avión aparece una pantalla en blanco o la página del sistema "no hay conexión".
• Un muro de login sin cuenta demo. Si el revisor no pasa del login, la app parece una carcasa vacía. (Además es un motivo de rechazo propio según la directriz 2.1, que pide "demo account info" si tu app tiene login.)
• Páginas de marketing en lugar de funciones. Si las primeras pantallas son una landing —hero, testimonios, banner de "descarga nuestra app"—, es el caso de "marketing materials" de la 4.2.2.
• Nada de lo que hace una app. Ningún motivo para tenerla en la pantalla de inicio en lugar de como marcador.

Cambios que de verdad cambian el resultado

1. Navegación de app

Dale a la app una barra de pestañas inferior con tus tres a cinco secciones principales (para una tienda: Inicio, Categorías, Carrito, Cuenta). Debe verse en todas las pantallas y usarse con un pulgar. Este único cambio combate la impresión de "colección de enlaces" mejor que cualquier otro.

2. Un estado sin conexión cuidado

Activa el modo avión y abre tu app. Si ves una página de error, el revisor puede verla también. Muestra una pantalla sin conexión con tu marca y un botón de reintentar, y recarga automáticamente cuando vuelva la conexión.

3. Oculta todo lo que diga "navegador"

• Usa un diseño móvil en todas partes; desactiva el zoom donde solo muestra una página de escritorio.
• Los enlaces internos se quedan en la app; solo los externos de verdad abren el navegador.
• Quita de la vista de la app los banners de "descarga nuestra app", los muros de cookies pensados para escritorio y los pies de página llenos de enlaces.

4. Empieza donde está el valor

La primera pantalla tras abrir la app debe ser la parte útil de tu producto —el catálogo, el panel, el flujo de reserva—, no tu página de inicio de marketing. Si tienes una página de inicio específica para la app, úsala.

5. Funciones del dispositivo con un propósito real

Notificaciones push para cosas que los usuarios quieren de verdad (pedido enviado, cita mañana), el menú de compartir, subir fotos con la cámara donde tu producto lo necesita. Evita los permisos decorativos: pedir ubicación o cámara sin un motivo visible es un riesgo de rechazo en sí mismo, y cada permiso necesita un texto de justificación claro.

6. Cuentas bien resueltas

Si los usuarios pueden crear una cuenta en tu app, aplica la directriz 5.1.1(v): "If your app supports account creation, you must also offer account deletion within the app." En las web apps, borrar la cuenta suele estar escondido en una página de ajustes de escritorio: hazlo accesible desde la app. Y dale a App Review una cuenta demo que funcione en App Store Connect.

Lo que no ayuda

• Añadir una pantalla nativa que nadie usa solo para tener "algo nativo".
• Solo la pantalla de inicio y el icono: necesarios, pero no suficientes.
• Copiar el aspecto de otra app. Los revisores valoran la utilidad de tu app, no su estilo.

Las reglas que casi nadie menciona: 4.2.6 y 4.3(a)

Si usas un creador de apps o un servicio de plantillas, lee estas dos antes de enviar.

4.2.6 "Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. These services should not submit apps on behalf of their clients […]"

En pocas palabras: la app debe enviarse desde tu propia cuenta de Apple Developer, no desde la del creador de apps. Un servicio que publica apps por ti con su propia cuenta pone en riesgo cada una de ellas.

4.3(a) "Don't create multiple Bundle IDs of the same app […]"

Si tienes varias webs parecidas —una por ciudad, por franquicia o, como agencia, por cliente—, enviar una app casi idéntica para cada una es el caso de manual de spam según la 4.3(a). Plantéate una sola app con selector, o haz que cada app sea realmente distinta.

Pagos: otra trampa para las web apps

Si tu web app vende contenido digital o suscripciones, la directriz 3.1.1 exige compras integradas dentro de la app de iOS ("If you want to unlock features or functionality within your app […] you must use in-app purchase"). Un checkout web para una suscripción digital dentro de la app es otro rechazo frecuente.

Los bienes físicos son distintos: según la 3.1.3(e), para "physical goods or services that will be consumed outside of the app" debes usar métodos de pago distintos de la compra integrada. Una tienda que vende productos reales mantiene su checkout habitual.

Cómo volver a enviarla

1. Primero corrige, después responde. Haz los cambios, sube una build nueva y luego contesta en App Store Connect.
2. Escribe notas de revisión concretas. La directriz 2.3.1(a) pide que las funciones nuevas se describan "with specificity in the Notes for Review section". Enumera qué has cambiado y dónde encontrarlo.
3. Añade una cuenta demo y, si tu app tiene funciones poco visibles, una grabación de pantalla corta.
4. Mantén un tono objetivo. Los revisores responden a pruebas, no a la frustración.

Una respuesta que sirve como punto de partida (en inglés, porque App Review suele comunicarse en inglés):

Thank you for the review. We've updated the app to address Guideline 4.2: – Added a bottom tab bar (Home, Shop, Cart, Account) available on every screen – Added an offline screen with automatic reload instead of a web error – The app now opens directly in the catalog instead of our marketing page – Account deletion is available under Account → Settings A demo account is included in App Review Information. Thank you for taking another look.

Si crees que el rechazo es injusto, puedes recurrir ante el App Review Board, pero solo cuando estés seguro de cumplir los puntos anteriores.

Checklist antes de enviar

• Navegación inferior con tus secciones principales, visible en todas las pantallas
• Pantalla sin conexión con tu marca y botón de reintentar, probada en modo avión
• Sin marco de navegador, sin diseño de escritorio, sin zoom en páginas móviles
• Los enlaces internos se quedan en la app
• Primera pantalla = el núcleo de tu producto, no la página de marketing
• Solo los permisos que usas, cada uno con un texto de justificación claro
• Borrado de cuenta accesible en la app (5.1.1(v)); cuenta demo en App Store Connect (2.1)
• Bienes digitales con compra integrada (3.1.1); bienes físicos con tu checkout habitual (3.1.3(e))
• Enviada desde tu propia cuenta de Apple Developer (4.2.6); una app, no una por ubicación (4.3(a))
• Notes for Review concretas (2.3.1(a))

Dónde encaja AppThunder

AppThunder construye en la nube la app de iOS y Android alrededor de tu web actual. Se encarga de los puntos de esta checklist que quedan fuera de tu web: icono y pantalla de inicio nativos, textos de justificación para los permisos de cámara y ubicación que actives, una pantalla sin conexión con tu marca que se recarga sola y una barra de pestañas para tu web mediante un fragmento de código para copiar y pegar. Las builds se firman con tus credenciales de Apple y se suben a tu App Store Connect, así que la envías desde tu propia cuenta, como exige la 4.2.6. Un Guideline Checker integrado señala problemas habituales —falta de página de privacidad, muro de login, falta de borrado de cuenta— antes de enviarla.

Lo que no puede hacer por ti: decidir qué muestra tu primera pantalla, darle a App Review una cuenta demo o convertir una página de marketing en algo útil. La checklist de arriba sigue siendo tuya.

Preguntas frecuentes

¿Puede aprobarse una app basada en WKWebView? Sí. La regla de Apple valora el resultado, no la tecnología: funciones, contenido e interfaz que "elevate it beyond a repackaged website".

¿Cuánto tarda una nueva revisión? Apple no publica plazos fijos. Eso sí, las directrices advierten que la revisión "will take longer" si una app es "repeatedly rejected for the same guideline violation", así que corrige todo antes de volver a enviarla.

¿Google Play tiene la misma regla? Google Play no tiene un equivalente directo a la 4.2, pero sus políticas de funcionalidad mínima y spam se aplican también a las apps que solo muestran una web. Las mismas mejoras ayudan en ambas tiendas.

¿Basta con una pantalla de inicio y un icono? No. Se dan por supuestos, pero no cambian cómo se comporta la app: eso lo hacen la navegación, el estado sin conexión y una primera pantalla útil.