Los motivos de rechazo en el App Store que más afectan a las apps en 2026

La mayoría de los rechazos en el App Store se reducen a seis guidelines. Cinco de las seis se pueden resolver antes de enviar la app. El propio texto de Apple indica que más del 40% de los problemas de revisión sin resolver proviene de una sola regla de completitud, así que una revisión breve contra estas seis evita la mayoría de los problemas antes de que un revisor vea tu build.

Fallos, errores y builds incompletos (2.1)

La guideline 2.1, App Completeness, es la primera que hay que resolver. El texto de Apple es directo: los envíos "should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission", y las apps deben estar "tested on-device for bugs and stability" antes del envío, con la información de la cuenta demo incluida y el servicio backend activo si la app tiene login.

En la práctica eso se traduce en tres cosas. Probar exactamente el build que se va a enviar en un dispositivo con la versión actual del sistema, no en un simulador con el sistema del año pasado. Eliminar cualquier imagen de relleno, texto lorem ipsum o pantalla de "próximamente". Y si alguna parte de la app está detrás de un login, hay que enviar credenciales de una cuenta demo que funcione y mantener el backend activo durante la ventana de revisión. Un revisor que no puede iniciar sesión no puede aprobar el resto de la app.

Apple también confirma que el 90% de los envíos reciben una decisión en menos de 24 horas, y que los envíos incompletos son la principal causa de que una revisión se alargue. Esto es justo lo que busca detectar la revisión de pruebas que hacemos antes de cada lanzamiento en SwiftUI, antes de que le cueste un ciclo de envío al equipo. La misma disciplina importa durante una migración a la concurrencia de Swift 6, donde un build que compila sin errores puede seguir fallando en tiempo real en un dispositivo que el simulador nunca puso a prueba.

Notas para revisión vagas o ausentes (2.3.1)

La guideline 2.3.1 exige precisión, no solo exactitud. El texto de Apple señala que las apps no deben incluir "any hidden, dormant, or undocumented features," y que "all new features, functionality, and product changes must be described with specificity in the Notes for Review section of App Store Connect (generic descriptions will be rejected)".

Una entrada en Notes for Review que diga "corrección de errores y mejoras" no le dice nada a un revisor. Una entrada útil nombra la funcionalidad exacta, explica por qué existe y describe qué debe hacer el revisor para verla funcionar, por ejemplo qué menú activa una función beta, o qué nivel de cuenta muestra una pantalla de pago. Si una funcionalidad depende de un flag de servidor o de una región concreta, hay que indicarlo en ese mismo campo.

No hay suficiente app para justificar el App Store (4.2)

La guideline 4.2, Minimum Functionality, filtra las apps que no hacen más de lo que ya hace un sitio web. El lenguaje de Apple: una app "should include features, content, and UI that elevate it beyond a repackaged website," y, salvo los catálogos, las apps "shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links."

Esta es la línea que traza Apple: una app que aprovecha capacidades nativas, acceso sin conexión, notificaciones push, sensores del dispositivo, frente a otra que es solo un envoltorio de navegador alrededor de un sitio de marketing con algunos botones extra. Si la única razón de que tu app exista en un teléfono es la comodidad, normalmente eso no basta.

Envíos repetidos, plantillas o spam (4.3)

La guideline 4.3, Design: Spam, apunta a apps construidas con el mismo código fuente o los mismos assets que una app ya existente en el Store con "only minor differences," incluyendo apps basadas en una plantilla comprada o reutilizada con solo cambios cosméticos, y varias apps similares enviadas desde distintas cuentas.

Apple señala algunas categorías que considera saturadas de entrada: astrología, horóscopos, lectura de la palma de la mano y apps similares de adivinación biométrica, sin importar la calidad del desarrollo. Si tu producto está en una categoría de plantillas saturada, la solución no es una apelación más contundente. Es enviar contenido y funcionalidad que realmente sea tuyo.

Vacíos en la política de privacidad y recolección de datos no declarada (5.1.1)

La guideline 5.1.1 exige una política de privacidad que haga un trabajo real, no una página genérica. Debe identificar qué datos recopila la app y cómo, describir todos los usos de esos datos, confirmar que cualquier tercero que maneje esos datos ofrece la misma protección, y explicar la retención, la eliminación y cómo un usuario puede revocar su consentimiento. La guideline 5.1.1(ii) va más allá: se requiere consentimiento para recopilar datos de uso incluso cuando esos datos son anónimos en el momento de la recolección.

Antes de enviar la app, conviene leer tu propia política de privacidad contra esa lista, punto por punto. Una plantilla genérica que nunca nombra tu SDK de analítica ni tu red publicitaria no pasará la revisión. Y un aviso de permiso de recolección de datos sin un purpose string en el Info.plist es un rechazo fácil de evitar bajo la misma guideline.

Desbloquear contenido fuera de la compra dentro de la app (3.1.1)

La guideline 3.1.1 es estrecha y no admite excepciones: suscripciones, moneda dentro del juego, niveles, contenido premium y acceso a la versión completa deben pasar todos por la compra dentro de la app, y las apps no pueden sustituir ese mecanismo por otro propio, como claves de licencia, códigos QR, marcadores de realidad aumentada o carteras de criptomonedas, entre los ejemplos que Apple nombra explícitamente.

Si tu plan de monetización evita el sistema de pago de Apple para cualquier contenido restringido dentro de la app, hay que esperar un rechazo bajo esta guideline, sin importar cómo se presente la funcionalidad. Las monedas dentro de la app tampoco pueden caducar, y cualquier compra restaurable necesita un mecanismo de restauración que funcione.

Cómo priorizar antes de enviar la app

El orden importa. Primero, resolver 2.1, porque explica la mayor parte de los rechazos no resueltos y está completamente bajo tu control: probar en dispositivo, eliminar contenido de relleno, enviar una cuenta demo que funcione. Después, escribir entradas específicas en Notes for Review para cualquier funcionalidad nueva o poco evidente. Luego, revisar la política de privacidad contra la lista de 5.1.1, punto por punto. Solo después de esos tres pasos vale la pena preocuparse por el posicionamiento de 4.2, la originalidad frente a 4.3 y la mecánica de monetización de 3.1.1, ya que esos puntos suelen ser decisiones de diseño tomadas mucho antes del envío, no ajustes de última hora.

Dado que la mayoría de las revisiones se resuelven en menos de 24 horas, un primer envío limpio casi siempre es más rápido que corregir y apelar después de un rechazo. Cinco de las seis categorías anteriores son puntos de una lista de comprobación, no decisiones de criterio, y las otras dos, 4.2 y 4.3, dependen de si la app se gana su lugar en el Store por mérito propio. Es la misma revisión de cumplimiento que aplicamos antes de cada envío al App Store, antes de que un build llegue siquiera a App Store Connect. Si quieres una segunda revisión de un envío antes de mandarlo, podemos ayudarte.

Preguntas frecuentes

¿Cuál es el motivo más común de rechazo de una app?

La guideline 2.1, App Completeness. Apple atribuye a esta guideline más del 40% de los rechazos no resueltos: fallos, builds incompletos, contenido de relleno, enlaces rotos y funciones con login sin una cuenta demo que funcione.

¿Cuánto dura realmente la revisión del App Store?

Apple indica que el 90% de los envíos reciben una decisión en menos de 24 horas. Los envíos incompletos, es decir, sin credenciales demo o con Notes for Review poco claras, son la principal causa de retraso más allá de esa ventana.

¿Se puede apelar un rechazo del App Store?

Sí, una apelación por cada envío rechazado, a través del formulario Submit an Appeal. Apple espera que antes se responda a cualquier información adicional que haya pedido el revisor, y que se explique con precisión por qué la app cumple la guideline citada.

¿Un sitio web reempaquetado cuenta como una app?

No, según la guideline 4.2, Minimum Functionality. Apple rechaza apps que son principalmente material de marketing, un agregador de contenido o un envoltorio delgado de un sitio web sin utilidad propia de app.

¿Qué debe incluir una política de privacidad para el App Store?

Según la guideline 5.1.1 debe indicar qué datos recopila la app y cómo, todos los usos de esos datos, que cualquier tercero que los maneje ofrece la misma protección, y cómo un usuario puede revocar su consentimiento o solicitar la eliminación de sus datos.