Rechazo de Apple: por qué rechazan tu app (5 casos reales)

Un rechazo de Apple casi siempre llega por una razón concreta, escrita en el mensaje de la revisión: una guideline numerada, a menudo acompañada de una captura. Los motivos más frecuentes en una primera app son una app que no está terminada (2.1), una privacidad mal declarada (5.1.1), metadatos engañosos (2.3.2), un pago que esquiva la compra integrada (3.1.1) o una solicitud de calificación mal ubicada (5.6.3). En la gran mayoría de los casos, el reviewer entendió bien tu app: lo que tenía puntos débiles era tu envío.

Lo sé porque recibí esos rechazos yo mismo. Publico mis propias apps iOS: Solys (un despertador con minijuegos) y TradaZen (un simulador de trading) están en el App Store. Solys recibió dos rechazos, uno antes de su lanzamiento y otro en una actualización, y otras dos apps, Clic y Nolera, fueron rechazadas, corregidas y reenviadas a Apple. Aquí están los cinco rechazos, su causa real, y luego el método para responder y la checklist que aplico antes de cada envío.

Por qué Apple rechaza una app: los 5 rechazos que recibí

Rechazo 2.1 en Solys: la demo era imposible de ganar

El onboarding de Solys ofrece una demo jugable: hay que ganar un minijuego, como al despertar. En mis teléfonos, todo funcionaba. El reviewer, en cambio, probaba en un iPad, donde una app de iPhone corre en modo de compatibilidad dentro de una ventana más pequeña. A ese tamaño, el hueco que se dejaba al pájaro del minijuego quedaba más estrecho que el propio pájaro, y el botón “Continuar” solo se activaba si ganabas. Apple pidió ofrecer una forma de saltar la misión del juego.

La corrección: una demo cuya geometría se calcula a partir del tamaño real de la pantalla, y un enlace para saltar la demo si fallas.

La lección: todo paso obligatorio debe tener una salida, y cada pantalla obligatoria se prueba en el formato más pequeño posible antes de cada envío.

Rechazo 5.6.3 en Solys: la solicitud de calificación durante el onboarding

Segundo rechazo, en la siguiente actualización. Apple escribió que la app pedía una calificación en el primer inicio o durante el onboarding. La pantalla de calificación llegaba justo después de la demo, antes de que el usuario hubiera vivido nada en la app.

La corrección: la solicitud se movió al final del recorrido, y solo aparece si el usuario acaba de ganar la demo.

La lección: cada solicitud sensible (calificación, notificación, suscripción, rastreo) llega después de una prueba de valor, nunca antes.

Rechazo 5.1.1 en Clic: la política de privacidad en línea no estaba actualizada

Clic genera contenido con IA, y la app sí tenía su pantalla de consentimiento. El problema estaba en otro lado: la política de privacidad publicada en el sitio era la versión antigua, y no describía todo lo que la app recopila.

La corrección: política completa publicada, resumen en inglés añadido, notas de revisión actualizadas.

La lección: Apple lee tu política en línea, no la que duerme en tu repositorio. Antes de cada envío, abre la URL declarada y verifica que diga lo que hace tu app.

Rechazo 5.1.1 en Nolera: un botón “Permitir” antes de la solicitud del sistema

Antes de la verdadera solicitud de acceso a la cámara de iOS, Nolera mostraba una pantalla explicativa con un botón “Permitir”. Para Apple, ese texto empuja a aceptar antes de la solicitud oficial del sistema.

La corrección: el botón ahora se llama “Continuar”, en los 8 idiomas de la app.

La lección: una pantalla que prepara un permiso explica, no decide en lugar del usuario. Las recomendaciones de Apple están en sus reglas de diseño sobre privacidad.

Rechazo 2.3.2 en Nolera: el ícono reutilizado como imagen promocional

Las suscripciones pueden tener una imagen promocional en App Store Connect. En dos suscripciones de Nolera, era simplemente el ícono de la app. Apple lo consideró no conforme.

La corrección: se quitaron las imágenes de las dos suscripciones y se volvió a crear el envío.

La lección: cada elemento de tu ficha se revisa, incluidos los que llenas sin pensar, como la clasificación por edad.

¿Cuáles son las guidelines que más rechazos causan?

Todas las reglas están en las App Review Guidelines. Las que más a menudo atrapan a una primera app:

2.1: App Completeness. La app se cierra, un botón no lleva a ninguna parte, una pantalla obligatoria no funciona en algún formato. Si tu app pide iniciar sesión, proporciona una cuenta de demostración en las notas de revisión; si no, el reviewer se queda bloqueado en la pantalla de inicio de sesión. Todo lo que hay que saber sobre este motivo está en mi guía de la guideline 2.1.

2.3: Metadata. Capturas que no muestran la app real, descripción que promete una función inexistente, imágenes promocionales no conformes.

3.1.1: In-App Purchase. Para desbloquear contenido o funciones digitales en la app, la regla general es la compra integrada de Apple. Las excepciones dependen del país y cambian: lee la versión actualizada de las guidelines antes de planear otro medio de pago. Todo el tema está en la página suscripciones in-app en iOS.

3.1.2: Subscriptions. Una app con suscripción debe mostrar claramente qué obtiene el usuario y a qué precio. Los errores clásicos de pantalla de pago están en paywall iOS: 7 errores de principiante.

4.3: Spam. La app se parece a otras mil o no aporta lo suficiente por sí misma. Es el rechazo más difícil de corregir: se previene desde la elección de la idea. Lo explico en detalle en la guía de la guideline 4.3.

5.1.1: Privacy. Declaraciones de recopilación que no coinciden con el comportamiento de la app, política de privacidad incompleta, permiso solicitado sin una explicación clara.

¿Cómo responder a un rechazo de Apple sin perder días?

Un rechazo no es un veredicto, es un ida y vuelta. El procedimiento que funciona:

1. Lee el motivo dos veces. El mensaje cita la guideline y a menudo adjunta una captura. Muchos desarrolladores responden otra cosa porque leyeron demasiado rápido.
2. Busca la causa real. Tanto en Clic como en Nolera, la causa real no era la que el texto hacía pensar a primera vista. Reproduce el problema en las condiciones del reviewer: mismo tipo de dispositivo, cuenta nueva, primer inicio.
3. Corrige el motivo, nada más. No es momento de agregar tres funciones: cada cambio amplía la superficie de revisión.
4. Responde en App Store Connect. Explica en dos frases concretas lo que corregiste, respondiendo al mensaje de App Review.
5. Apela solo si estás seguro. Apple permite recurrir al App Review Board si crees que tu app fue malinterpretada, con una sola apelación por envío rechazado. Impugnar un rechazo merecido es perder el tiempo.

En cuanto a plazos, Apple indica que revisa al menos el 50 % de los envíos en menos de 24 horas, y el 90 % en menos de 48 horas. Son los rechazos los que alargan el calendario, no la fila de espera: el detalle está en plazo de aprobación del App Store. El proceso completo después de un rechazo está en la página app rechazada por Apple.

Un rechazo evitable cuesta un ciclo de revisión completo. La mejor respuesta a Apple es el envío que no le deja nada que reprochar.

La checklist que aplico antes de cada envío

Construida rechazo tras rechazo, con mis apps:

• Cada pantalla obligatoria probada en el iPhone más pequeño, en el más grande y en iPad en modo de compatibilidad, según la tabla de la guideline 4.0 de diseño
• Una salida posible en cada paso del onboarding, incluso si el usuario falla
• Cuenta de demostración en las notas de revisión si la app tiene inicio de sesión
• Compras probadas en sandbox, restauración incluida
• Precio, duración y enlaces a los términos y a la privacidad presentes donde Apple los exige, en cada idioma
• Política de privacidad en línea releída el día del envío
• Declaraciones de privacidad alineadas con lo que la app recopila realmente, privacy manifest incluido
• Pantallas previas a un permiso sin botón “Permitir”
• Solicitudes de calificación y de notificación ubicadas después de una prueba de valor, sin desbloquear nada a cambio de una calificación (guideline 3.2.2)
• Imágenes promocionales y capturas que muestran la app real, incluso en tus páginas de producto personalizadas

Si es tu primera publicación, la página publicar una app en el App Store repasa todos los pasos antes del envío.

Una plantilla para explicarle tu recorrido a App Review

Descarga la plantilla de notas para App Review: instrucciones en francés, notas en inglés para completar y un esquema de respuesta a un rechazo. Te hace precisar la versión, el camino por las pantallas y el resultado esperado. Conserva solo lo que existe en tu build.

Reemplaza “la app guarda correctamente” por un escenario reproducible: pantalla de partida, acción, cierre y reapertura, resultado recuperado. Después de un rechazo, cita el comportamiento corregido y el dispositivo en el que lo verificaste. Si no lograste reproducir el problema, explica qué falta para reproducirlo.

Las credenciales de una cuenta de demostración se ingresan en los campos dedicados de App Store Connect, nunca en un archivo público. Puedes preparar las pruebas con la tabla de pruebas de TestFlight y encontrar las cinco plantillas gratuitas.

Evitar estos rechazos antes del envío

El Apple Review Kit reúne mi checklist antes del envío, mis rechazos de Apple corregidos y skills de Claude Code que revisan tu proyecto, tu paywall y tu ficha antes del envío.

¿Tu app ya fue rechazada? El kit te ayuda a encontrar la regla citada, lo que exige, y un ejemplo de corrección y de respuesta. Si quieres que revisemos tu caso juntos desde ya, reserva una hora conmigo, por videollamada.

Nadie puede garantizar que Apple acepte tu app. Partir de rechazos ya vividos simplemente reduce las probabilidades de caer en los mismos.

¿Todavía no enviaste tu app? El diagnóstico gratuito te envía mi checklist contra rechazos de Apple y te dice lo que te falta por hacer. Si todavía la estás construyendo, la página de inicio muestra cómo crear una app móvil teniendo en cuenta estos rechazos.

Preguntas frecuentes

¿Por qué Apple rechaza mi app?

Casi siempre por una razón concreta, escrita en el mensaje de la revisión: una guideline numerada, a menudo acompañada de una captura. En una primera app, los motivos más frecuentes son una app que no está terminada (2.1), una privacidad mal declarada (5.1.1) y metadatos engañosos (2.3.2). También están un pago que esquiva la compra integrada (3.1.1) y una solicitud de calificación mal ubicada (5.6.3).

¿Por qué rechazan mi app si funciona en mi iPhone?

Porque el reviewer puede probar en condiciones distintas a las tuyas. En Solys, mi despertador con minijuegos, probaba en un iPad, donde una app de iPhone corre en modo de compatibilidad dentro de una ventana más pequeña. Ahí la demo era imposible de ganar. La corrección: una demo calculada según el tamaño real de la pantalla, y un enlace para saltarla si fallas.

¿Qué hacer cuando Apple rechaza mi app?

Lee el motivo dos veces y luego busca la causa real reproduciendo el problema en las condiciones del reviewer: mismo tipo de dispositivo, cuenta nueva, primer inicio. Corrige el motivo y nada más, porque cada cambio amplía la superficie de revisión. Después responde en App Store Connect, con dos frases concretas sobre lo que corregiste.

¿Se puede impugnar un rechazo de Apple?

Sí, pero solo si estás seguro de tener razón. Apple permite recurrir al App Review Board si crees que tu app fue malinterpretada, con una sola apelación por envío rechazado. Impugnar un rechazo merecido es perder el tiempo. Si no, corrige el motivo y responde en App Store Connect.

¿Un rechazo alarga el plazo de publicación?

Sí. Apple indica que revisa al menos el 50 % de los envíos en menos de 24 horas, y el 90 % en menos de 48 horas: son los rechazos los que alargan el calendario, no la fila de espera. Un rechazo evitable cuesta un ciclo de revisión completo. El detalle de los plazos está en plazo de aprobación del App Store.

¿Qué revisar antes de enviar una app a Apple?

Prueba cada pantalla obligatoria en el iPhone más pequeño, en el más grande y en un iPad en modo de compatibilidad, y luego prueba las compras en sandbox, restauración incluida. Relee tu política de privacidad en línea el día del envío y proporciona una cuenta de demostración en las notas de revisión si la app tiene inicio de sesión. Esta checklist se construyó rechazo tras rechazo, con mis apps.