Por qué Apple rechaza tu app y cómo superar la revisión
Si Apple te ha rechazado la app, en la inmensa mayoría de los casos no es un capricho del revisor: es una de las siete u ocho causas de siempre, y casi todas se arreglan en días, no en meses. Apple publica las reglas del juego en sus App Store Review Guidelines, y cada rechazo llega con el número de directriz incumplida. Ese número es tu mapa: dice exactamente qué revisar. Lo importante es entender que la revisión no es un trámite administrativo al final del proyecto, sino un requisito más del desarrollo que conviene tener en cuenta desde el principio.
Cómo funciona la revisión antes de que tu app se publique
Cuando envías una versión desde App Store Connect, una persona del equipo de App Review la instala, la usa y comprueba que cumple las directrices. Si algo falla, recibes un mensaje con la directriz incumplida y, a menudo, una captura del problema. La app queda en estado rechazado y no se publica hasta que respondas con una corrección o con una explicación aceptada.
Ese diálogo ocurre en el Centro de Resoluciones de App Store Connect. Puedes responder ahí mismo: aportar información, aclarar un malentendido o avisar de que subes una versión corregida. Si consideras que la interpretación del revisor no es correcta, existe la vía de solicitar que se revise la decisión, además de la de corregir y reenviar.
Las causas de rechazo que más se repiten
Estas son las directrices con las que más se topa una empresa que publica su primera app, con lo que significan en la práctica.
| Directriz | Qué exige Apple | Fallo típico |
|---|---|---|
| 2.1 App Completeness | Enviar una versión final, probada y con los datos necesarios para revisarla | Cuentas de demostración caducadas, pantallas a medias, fallos al abrir |
| 2.3 Accurate Metadata | Que descripción, capturas y categoría reflejen lo que la app hace de verdad | Capturas de una versión antigua o funciones anunciadas que no existen |
| 2.5 Software Requirements | Usar solo API públicas y funcionar en la versión actual del sistema | Descargar código que cambia el comportamiento tras la aprobación |
| 3.1.1 In-App Purchase | Vender el contenido digital que desbloquea funciones mediante compra integrada | Cobrar suscripciones digitales por fuera o con códigos de activación |
| 4.2 Minimum Functionality | Aportar algo más que una web reempaquetada | Una app que solo abre tu página dentro de un marco |
| 4.3 Spam | No publicar apps duplicadas o indistinguibles de otras existentes | Una app por cada cliente, idéntica salvo el logotipo |
| 5.1.1 Data Collection | Enlace a la política de privacidad en la ficha y dentro de la app, y etiquetas de privacidad veraces | Política inexistente, enlace roto o etiquetas que no coinciden con los datos que recoges |
Fíjate en el patrón: casi ninguna es una cuestión de programación avanzada. Son cosas que se preparan antes de darle al botón de enviar.
El rechazo que más duele: «tu app es una web»
La directriz 4.2 tumba proyectos enteros y es la que conviene entender antes de encargar el desarrollo. Apple espera que una app ofrezca utilidad propia y no se limite a mostrar dentro de un marco lo que ya se ve en el navegador. Si tu proyecto se resume en «queremos nuestra web en la App Store», tienes un problema de planteamiento, no de envío.
La forma de salir es dotar a la app de capacidades que solo tienen sentido en el móvil: notificaciones útiles y personalizadas, funcionamiento sin conexión, cámara, lectura de códigos, ubicación, agenda, biometría para entrar sin contraseña o integración con la cartera. Si ninguna de esas piezas encaja con tu negocio, quizá la respuesta correcta sea una web bien hecha y adaptada al móvil en lugar de una app.
Privacidad: el bloque que más rechazos acumula
La directriz 5.1.1 exige una política de privacidad accesible desde la ficha de la App Store y también desde dentro de la aplicación, que explique con claridad qué datos recoges, para qué los usas, con quién los compartes y cómo se eliminan. A eso se suman las etiquetas de privacidad de la ficha, que deben coincidir con lo que la app hace de verdad, y el permiso de seguimiento cuando corresponde.
Si operas en España, este trabajo se solapa con el que ya te exige el Reglamento General de Protección de Datos, así que aprovéchalo: una política de privacidad bien redactada te sirve para las dos cosas. Dos detalles que fallan mucho: pedir el registro obligatorio para ver contenidos que no lo necesitan, y recoger datos que nadie ha declarado en las etiquetas porque venían con una librería de terceros.
Cómo preparar el envío para aprobar a la primera
Una lista de comprobación antes de enviar evita la mayoría de los rechazos:
- Cuenta de demostración operativa, con datos de ejemplo y permisos suficientes, y anotada en las notas para el revisor.
- Notas para el revisor explicando qué hace la app, cómo probarla y qué justifica cualquier función que pueda parecer dudosa.
- Prueba en dispositivo real y en la versión actual del sistema, no solo en simulador.
- Todos los enlaces vivos: política de privacidad, soporte y condiciones.
- Capturas actualizadas de la versión que envías, sin funciones que no estén disponibles.
- Permisos con textos explicativos concretos: por qué necesitas la cámara o la ubicación, en lenguaje comprensible.
- Compras integradas configuradas y enviadas junto a la versión, no después.
- Nada de contenido de relleno: si una sección está vacía o dice «próximamente», mejor quítala.
Qué hacer cuando ya te han rechazado
Con la calma por delante, el proceso es sencillo. Lee el mensaje entero y localiza el número de directriz. Abre el texto de esa directriz en el sitio para desarrolladores de Apple y compruébalo con tu app en la mano, sin dar por hecho que el revisor se ha equivocado. Si el problema es real, corrígelo y sube una versión nueva explicando en las notas qué has cambiado.
Si de verdad crees que hay un malentendido —por ejemplo, el revisor no encontró una función porque hacía falta un dato concreto—, responde en el Centro de Resoluciones aportando pasos, capturas o un vídeo corto. Sé específico y cortés: al otro lado hay una persona revisando muchas aplicaciones al día. Lo que nunca funciona es reenviar la misma versión sin cambios ni explicación, ni intentar ocultar una función para activarla después de la aprobación: eso incumple la directriz 2.5 y puede costarte la cuenta de desarrollador.
Cómo afecta esto a tus plazos y a tu contrato
Planifica la revisión como una fase más del proyecto, con margen para una corrección y un segundo envío, especialmente si el lanzamiento está atado a una campaña o a una feria. Y deja claro en el contrato con tu proveedor quién se ocupa de preparar la ficha, las etiquetas de privacidad y las respuestas al revisor, y si están incluidas las correcciones derivadas del rechazo. Es una de esas cosas que nadie discute hasta que aparece el primer rechazo.
Ten en cuenta también que aprobar no es para siempre: Apple actualiza sus directrices y su sistema cada año, y una app que no se mantiene puede dejar de cumplir requisitos con el tiempo.
En resumen: la revisión se prepara, no se sufre
La mayoría de los rechazos se explican por cuatro cosas: la app no está terminada, la ficha no coincide con lo que hace, la privacidad no está bien resuelta o el proyecto no aporta nada frente a la web. Trabaja esas cuatro desde el principio, prepara la cuenta de demostración y unas notas claras, y el envío deja de ser una lotería. Si estás desarrollando una app y quieres que alguien revise contigo el planteamiento y la ficha antes de enviarla a Apple, cuéntanos tu proyecto y te decimos qué puntos conviene atar antes.