App rechazada en App Store: por qué pasa y cómo conseguir que la aprueben

Que te rechacen una app en App Store es normal, sobre todo la primera vez, y casi siempre tiene arreglo. El rechazo llega con el número de la norma incumplida de las App Review Guidelines (las guidelines de App Store, actualizadas por última vez el 16 de octubre de 2026) y, muchas veces, con una captura de lo que vio el revisor.

Aquí tienes los motivos de rechazo más frecuentes según la propia Apple, lo que dice cada norma en castellano llano, cómo contestar sin alargar el proceso y qué hacer si crees que el revisor se ha equivocado.

Los motivos de rechazo más frecuentes en App Store

Esta es la lista que publica Apple en su página de App Review, con la norma correspondiente:

Más del 40 % de los problemas sin resolver son de la 2.1. Es decir, casi la mitad de los rechazos se evitan antes de enviar, sin tocar el diseño ni el modelo de negocio.

Las normas que más sorprenden a quien publica por primera vez

5.1.1(v): borrar la cuenta desde la app

Si tu app permite crear una cuenta, tiene que permitir borrarla desde dentro de la app. Un enlace a un correo de soporte no basta.

4.8: inicio de sesión con Google o Facebook

Si usas un inicio de sesión de terceros para la cuenta principal (Google, Facebook, X, LinkedIn, Amazon, WeChat), tienes que ofrecer también otro equivalente que recoja como mucho nombre y correo, que permita ocultar el correo y que no rastree para publicidad sin consentimiento. Iniciar sesión con Apple cumple las tres condiciones.

3.1.1: pagos de contenido digital

Si lo que vendes se usa dentro de la app (suscripciones, monedas, niveles, contenido premium), tiene que ir por compra dentro de la app. Los bienes y servicios que se consumen fuera, como un pedido de comida o un viaje, van con otro medio de pago (3.1.3(e)). Las normas tienen excepciones para la tienda de EE. UU. que no aplican en España.

4.2.6 y 4.3: plantillas, generadores y apps «de fin de semana»

Las apps creadas con una plantilla comercial o un servicio generador se rechazan salvo que las envíe el dueño del contenido. Y la 4.3 cita por su nombre categorías saturadas (linternas, fondos de pantalla, temporizadores simples, adivinación, citas, efectos de sonido) donde solo se aceptan apps realmente distintas. Si has hecho tu app con IA en unos días, este es el punto que más te conviene leer.

2.3.10: nada de otras plataformas

Ni en la app ni en la ficha puede haber nombres, iconos o imágenes de otras plataformas móviles o tiendas alternativas. Una captura con «Disponible también en Google Play» es un rechazo.

¿Qué hacer cuando te rechazan la app?

1. Lee el mensaje entero en la sección App Review de App Store Connect. Apunta el número exacto de norma y mira si hay capturas adjuntas: suelen enseñar el punto exacto donde falló.
2. Decide si es código o ficha. Si el problema está en los metadatos (capturas, descripción, notas), no hace falta un build nuevo: corriges la ficha y reenvías la misma versión.
3. Si no entiendes qué te piden, contesta en el mismo hilo preguntando qué pantalla o qué flujo concreto incumple. También puedes pedir una llamada con un representante de Apple desde la ayuda de App Review.
4. Corrige y responde explicando qué has cambiado, en una o dos frases por punto. Si el revisor no encontró una función, di dónde está, paso a paso.
5. Reenvía. El nuevo envío vuelve a la cola de revisión.

Error típico: contestar con un texto largo, defensivo y genérico, o reenviar sin decir nada esperando que toque otro revisor. Funciona mucho mejor algo así: «Norma 2.1: el revisor no pudo iniciar sesión. Hemos añadido en Sign-in required la cuenta demo@tuapp.com, que no caduca, y en las notas los pasos para llegar a la función de pago (Perfil › Plan › Mejorar)».

Recurrir o pedir revisión acelerada

Nuestro criterio: guarda el recurso para cuando de verdad tengas razón y puedas demostrarlo con la letra de la norma. Como solo hay uno por envío, gastarlo en algo que se arregla en una hora con un cambio en la ficha es tirarlo. En la mayoría de rechazos, la vía rápida es corregir y explicar, no discutir.

Lista de comprobación antes de enviar (y de reenviar)

• Probada en dispositivo real con la versión de iOS más antigua que soportas, sin cuelgues.
• URL de soporte con datos de contacto reales y política de privacidad que cargan.
• Cuenta de demostración que no caduca en Sign-in required.
• Notas para la revisión concretas: qué hace la app, dónde están las funciones de pago, qué hardware o contenido externo necesita. Las descripciones genéricas se rechazan (norma 2.3.1(a)).
• Si hay cuentas, se pueden borrar desde la app.
• Si hay inicio de sesión de terceros, hay una alternativa que cumple la 4.8.
• Contenido digital por compra dentro de la app.
• Textos de propósito en cada permiso.
• Capturas actuales, con la app en uso, sin precios ni referencias a Android.
• Nada de relleno, botones muertos ni pantallas «próximamente».
• Clasificación por edad contestada con el cuestionario nuevo.

Si quieres que le echemos un ojo antes de enviarla

Revisamos la ficha y los metadatos contra las normas como parte del servicio de lanzamiento de apps. Si tu app ya está publicada y lo que quieres es que la encuentren, empieza por la auditoría ASO gratuita.