Un rechazo de la App Store llega como un mensaje en App Store Connect: un número de directriz, unas frases del revisor y, a menudo, una captura de la pantalla que falló. No es un veredicto sobre su app ni sobre su cuenta. App Review de Apple gestionó más de 9,1 millones de envíos en 2025, la mayoría en menos de 24 horas, y una buena parte de los primeros envíos vuelven al menos una vez. Lo que importa es lo que hace en la hora siguiente al mensaje.
Esa decisión se reduce a tres preguntas. ¿Tiene razón el revisor? ¿La corrección necesita un nuevo build o solo un cambio en la ficha? Y si no está de acuerdo, ¿responde o apela? Esta guía las contesta en orden: cómo le llega un rechazo y qué significan los estados, los ocho motivos que cubren la mayoría de los rechazos, las tres respuestas posibles y una checklist para el reenvío.
Si está en una fase anterior del recorrido, nuestra guía sobre cómo publicar una app en la App Store cubre todo el camino desde la cuenta de desarrollador hasta el lanzamiento; este artículo empieza el día en que la revisión vuelve negativa.
Cómo le llega un rechazo y qué significan los estados
App Review combina comprobaciones automáticas, que detectan cierres inesperados, uso de API privadas y malware, con un revisor humano que instala su build, abre la ficha, lee sus notas de revisión y usa la app como lo haría un cliente. Cuando algo falla, el revisor escribe un mensaje en el Centro de resolución (Resolution Center) de App Store Connect y la versión cambia de estado. Tres estados importan:
- Rejected. El propio binario tiene un problema: un cierre inesperado, una función que falta, un problema de permisos. Casi siempre tendrá que subir un nuevo build.
- Metadata Rejected. El build está bien; la ficha no. Capturas, descripción, palabras clave, respuestas de privacidad o notas de revisión necesitan un cambio, que hace directamente en App Store Connect y reenvía sin un nuevo build.
- Developer Rejected. Usted mismo retiró la versión, por ejemplo para sustituir un build. Nada que responder.
Los ocho motivos detrás de la mayoría de los rechazos en el primer envío
Las App Review Guidelines ocupan cinco capítulos y decenas de reglas, pero los rechazos que un primer envío recibe de verdad se concentran en un puñado. Aquí están, con lo que vio el revisor y lo que lo corrige.
| Directriz | Lo que vio el revisor | Lo que lo corrige |
|---|---|---|
| 2.1 Performance | La app se cerró al iniciarse o en un flujo principal en el dispositivo del revisor | Reprodúzcalo en el binario de TestFlight, en varios dispositivos y versiones de iOS, y corríjalo. No adjunte nada; suba un nuevo build. |
| 2.1 App completeness | Una cuenta de demostración que no funciona, contenido provisional, una función marcada como «próximamente» | Facilite un inicio de sesión que funcione con datos realistas en App Review Information; elimine o termine los elementos provisionales. |
| 2.3 Accurate metadata | Las capturas o la descripción muestran funciones que no están en el build | Metadata Rejected: actualice las capturas y los textos para que coincidan con la app, reenvíe el mismo build. |
| 4.2 Minimum functionality | Un sitio web en un marco, o una app que hace demasiado poco para justificar una instalación nativa | Añada valor nativo: uso sin conexión, notificaciones, funciones del dispositivo, una experiencia que el sitio web no ofrece. |
| 4.3 Spam | Una app que duplica otra, suya o de una plantilla, en una categoría saturada | Diferénciela de forma sustancial, o fusione las variantes en una sola app. |
| 5.1.1 Data collection and storage | URL de política de privacidad ausente, etiquetas de App Privacy que contradicen la app, solicitudes de permiso sin motivo, aviso de seguimiento ausente | Publique la política, alinee las etiquetas con lo que la app recoge de verdad, escriba un texto de propósito para cada permiso, muestre el aviso de App Tracking Transparency si rastrea. |
| 3.1.1 In-app purchase | Contenido digital o suscripciones vendidos fuera de la compra integrada de Apple | Use la compra integrada para los bienes digitales; el pago externo sigue permitido para bienes físicos y servicios consumidos fuera de la app. |
| 1.5 Developer information | Una URL de soporte que devuelve un error o una página sin forma de contactar con usted | Metadata Rejected: apunte la URL de soporte a una página activa con un formulario de contacto o un correo. |
El caso especial de los sitios web envueltos
La directriz 4.2 es la que sorprende a los fundadores que empaquetaron su sitio web en una app. La postura de Apple es constante: si la app es el sitio web en una WebView sin nada que el navegador no pudiera hacer, no tiene sitio en la App Store. La solución no es una mejor descripción; es funcionalidad. Acceso sin conexión, notificaciones push, funciones de cámara o ubicación, una navegación nativa que el sitio no tiene. Si el proyecto empezó como una app web, la vía honesta es un build nativo de verdad, y por eso nuestra guía para crear una app móvil sin programar separa las herramientas que generan código nativo de las que envuelven un sitio.
Cómo responder: corregir, contestar o apelar
Lea el mensaje como una checklist
Antes de decidir nada, extraiga del mensaje el número de directriz, el paso exacto que describe el revisor, el dispositivo y la versión de iOS anotados en la parte superior, y cualquier captura adjunta. Después reprodúzcalo usted mismo en el mismo build a través de TestFlight. La mitad de las veces el revisor tiene razón y usted no lo había visto; una cuarta parte de las veces el revisor se encontró con un entorno que no probó, como una instalación limpia sin datos; el resto es un desacuerdo real.
Corregir y reenviar
Para un estado Metadata Rejected, edite la ficha en App Store Connect y pulse reenviar: sin nuevo build, y la segunda revisión suele ser rápida. Para un estado Rejected, suba un build corregido, selecciónelo en la misma versión y envíe de nuevo. En ambos casos, escriba una nota breve en el Centro de resolución diciendo qué ha cambiado. Los revisores la leen, y orienta la segunda revisión hacia la corrección en lugar de empezar de cero.
Responder cuando el revisor se equivoca
Si no puede reproducir el problema o la directriz no aplica, conteste en el Centro de resolución en lugar de reenviar el mismo build en silencio. Sea factual: los pasos exactos que siguió, el dispositivo y la versión, una grabación de pantalla que muestre la función funcionando, las credenciales que hay que usar. Si el revisor entendió mal lo que hace la app, explique el caso de uso en dos frases. También puede solicitar una llamada telefónica de App Review en el mismo hilo; no es rápido, pero desbloquea las conversaciones que el texto no consigue resolver.
Apelar ante el App Review Board
Una apelación sirve para un desacuerdo sobre la propia directriz, no sobre un hecho. Va al App Review Board mediante el formulario enlazado desde el rechazo, y tarda días, a veces más. Úsela después de que la respuesta en el Centro de resolución haya fallado, y escríbala para alguien que nunca ha visto su app: qué hace, qué directriz se citó, por qué cree que no aplica. Si la directriz ha cambiado hace poco, o si cree que se está aplicando de forma incoherente, dígalo y dé ejemplos.
La revisión acelerada
Apple concede una revisión acelerada para la corrección de un fallo crítico en una app publicada o para un evento con fecha, no para un primer lanzamiento que va tarde. Pedirla para un lanzamiento se rechaza y hace perder un día. Si su fecha límite es real, la única palanca es enviar pronto y responder a cualquier mensaje en cuestión de horas.
Una checklist para evitar el segundo rechazo
La mayoría de los segundos rechazos repiten el primero, o sacan a la luz el siguiente problema al que el revisor no llegó porque el primero detuvo la revisión. Antes de reenviar, repase esta lista una vez:
- El binario de TestFlight se abre en una instalación limpia, sin datos, en la versión de iOS más antigua que admite.
- La cuenta de demostración de App Review Information inicia sesión, y los datos que hay detrás parecen reales.
- Cada solicitud de permiso tiene un texto de propósito que dice qué hace la función con los datos.
- La URL de la política de privacidad se abre, y las respuestas de App Privacy coinciden con los SDK de la app.
- Las capturas muestran pantallas que existen en este build, en los tamaños de dispositivo correctos.
- Toda compra digital pasa por la compra integrada, y toda compra física es claramente física.
- La URL de soporte y la URL de marketing cargan y ofrecen una forma de contactar con usted.
- Los textos provisionales, los botones de prueba y las pantallas de «próximamente» han desaparecido.
- Las notas de revisión explican todo lo inusual: un requisito de hardware, una función limitada a una región, un inicio de sesión mediante un tercero.
Si construye con el creador de apps móviles de Cadrant, las partes del proceso que causan rechazos a nivel de build ya están resueltas: el binario nativo se compila y se firma en su cuenta de Expo, se envía a su App Store Connect, y la app es una aplicación Expo real y no un sitio web envuelto, lo que deja fuera la directriz 4.2. Lo que sigue siendo suyo es exactamente esta checklist: la ficha, las respuestas de privacidad, la cuenta de demostración y una pasada por TestFlight antes de pulsar enviar. La documentación de publicación enumera los pasos de App Store Connect en orden.
En resumen
- Un rechazo es un mensaje con un número de directriz; el estado le dice si el fallo está en el build o en la ficha.
- Ocho directrices explican la mayoría de los primeros rechazos: cierres inesperados, cuenta de demostración, metadatos, funcionalidad mínima, spam, privacidad, compra integrada, URL de soporte.
- Corrija y reenvíe cuando el revisor tiene razón, responda con pruebas cuando los hechos son erróneos, apele solo cuando lo que se discute es la propia directriz.
- Responda en el mismo día, y repase la checklist antes de cada reenvío.
Gestionado así, un rechazo cuesta uno o dos días, no un lanzamiento. Las apps que se quedan atascadas son las que reenvían el mismo build esperando que les toque otro revisor.