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.
Artículos relacionados
Preguntas frecuentes sobre
Cómo mejorar mi negocio con la metodología Anticompetencia
En Tangram no queremos que la información pase por una cadena interminable de intermediarios donde se pierden los detalles importantes.
Contarás con un interlocutor que coordinará la comunicación y trasladará las decisiones al equipo responsable de tu proyecto.
Cuando sea necesario profundizar en cuestiones de estrategia, diseño o tecnología, podremos involucrar a los especialistas correspondientes.
Así tendrás una comunicación organizada, sin necesidad de gestionar personalmente a todos los profesionales que intervienen.
Queremos que tengas acceso al conocimiento de un equipo especializado, sin sufrir la complejidad de coordinarlo.
No tendrás que averiguar a quién escribir cada vez que tengas una duda.
En Tangram contemplamos la figura del Account Manager como interlocutor principal, encargado de acompañarte durante el proyecto, coordinar la comunicación y facilitar el seguimiento de las decisiones.
Nuestra metodología incluye reuniones de revisión, canales de comunicación y herramientas para que puedas participar en el trabajo.
La organización concreta, la frecuencia de las reuniones y los canales disponibles se establecerán según el proyecto contratado.
Lo importante es que sepas con quién hablar, en qué punto está tu proyecto y qué decisiones necesitan tu participación.
Sí, podemos valorar una colaboración con los profesionales que ya trabajan en tu empresa.
No siempre tiene sentido sustituir un equipo que conoce bien tu negocio. En muchas situaciones, lo más útil es complementar sus conocimientos con especialistas en determinadas áreas.
Podemos estudiar qué responsabilidades asumiría Tangram, cuáles mantendría tu equipo y cómo coordinar las decisiones para evitar duplicidades.
La forma concreta de colaboración dependerá de la organización, las herramientas y las necesidades del proyecto.
No se trata de reemplazar lo que ya funciona, sino de aportar el conocimiento que necesitas para llegar más lejos.
No tienes por qué cambiar de proveedor para explorar una colaboración con Tangram.
Durante nuestra trayectoria hemos trabajado con agencias y consultoras, participando en proyectos en los que cada empresa asumía una parte diferente del trabajo.
Esa experiencia nos permite comprender la importancia de definir responsabilidades y coordinar a los profesionales implicados.
Podemos valorar una colaboración para cubrir necesidades concretas que tu proveedor actual no ofrece o para reforzar determinadas áreas.
Si tienes una relación profesional que funciona, no queremos que la rompas sin motivo. Queremos encontrar dónde podemos aportar valor.
La confidencialidad es especialmente importante cuando hablamos de nuevas ideas de negocio, información económica, estrategias comerciales o desarrollos tecnológicos.
En Tangram tenemos experiencia trabajando en proyectos sujetos a acuerdos de confidencialidad, motivo por el que no podemos mostrar públicamente muchos de los trabajos en los que hemos participado.
Si tu proyecto requiere un acuerdo de confidencialidad (NDA) antes de compartir información sensible, podemos revisar sus condiciones y acordar cómo proteger esa información antes de entrar en los detalles.
Entendemos que la confianza empieza por respetar lo que todavía no quieres hacer público.