Rechazo en el App Store: cómo solucionarlo, directriz por directriz (2026)

Un rechazo en el App Store es un mensaje de App Review que cita una directriz, describe lo que vio el revisor y retiene el lanzamiento hasta que lo corrijas, lo expliques o apeles. Empieza por convertir ese mensaje en un problema que puedas probar. El siguiente paso depende de si el revisor no pudo usar la app, encontró un incumplimiento de las normas o necesita más información. A octubre de 2026, las App Review Guidelines se actualizaron por última vez el 16 de octubre de 2026, así que comprueba la numeración vigente antes de citar una sección.

¿Qué te dice realmente un mensaje de rechazo del App Store?

Un mensaje de rechazo del App Store indica la directriz que aplicó el revisor, describe el comportamiento concreto que observó y enumera los siguientes pasos. A menudo incluye el dispositivo, la versión de iOS y capturas de pantalla.

Guarda el mensaje completo, las capturas, el número de build y los datos del dispositivo. Lee la sección citada en la página vigente de las directrices. Luego escribe una frase: "El revisor no pudo completar X porque Y". Si el mensaje pide información que falta en lugar de señalar un defecto, anota exactamente qué falta. El texto estándar de Apple para la 2.1 también explica cómo reproducir el problema: "En apps nuevas, desinstala todas las versiones anteriores de tu app de un dispositivo y, después, instálala y sigue los pasos para reproducir el problema".

• ¿El mensaje menciona un cierre inesperado, una pantalla inaccesible o una función incompleta? Reproduce ese flujo en la build de lanzamiento enviada, en el tipo de dispositivo que indicó Apple.
• ¿Menciona las capturas de pantalla, la descripción o las notas para la revisión? Comprueba si puedes corregirlo solo en los metadatos.
• ¿Menciona pagos, inicio de sesión, privacidad o funcionalidad mínima? Compara el comportamiento del producto con la directriz citada.

¿Qué directrices citan los rechazos del App Store y qué exigen?

Cada directriz establece un requisito concreto, así que relaciona el número citado con su redacción y haz las pruebas en función de ese texto. La tabla cita el texto actual de las directrices que suelen aparecer en los mensajes de rechazo.

La actualización del 16 de octubre de 2026 añadió la 2.5.19 para funciones ocultas, latentes o no documentadas, que antes se trataban en la 2.3.1. También añadió la 2.3.14 sobre recursos creativos e integró el entitlement de Music Streaming Services en el entitlement StoreKit External Purchase Link dentro de la 3.1.1(a). Toma la tabla como punto de partida, no como una solución garantizada. Una misma directriz puede abarcar problemas distintos, y el ejemplo del revisor es el caso concreto que tienes que resolver.

¿Cómo se soluciona un rechazo por la 4.2 de funcionalidad mínima?

Un rechazo por la 4.2 se soluciona aportando valor real como app, no reescribiendo la descripción. La directriz 4.2 dice: "Si tu app no es especialmente útil, única o 'propia de una app', no tiene cabida en el App Store".

Pregúntate qué puede hacer alguien en tu app que la haga útil como app. Puede completar un flujo de trabajo, guardar un estado relevante, usar las capacidades del dispositivo de una forma coherente con la app u obtener una experiencia móvil pensada para el dispositivo. Ninguna lista de funciones publicada garantiza la aprobación. Si esos flujos ya existen, enuméralos en las notas para la revisión con pasos exactos y capturas. Si la app se limita sobre todo a mostrar una página web, necesita trabajo de producto. Añadir notificaciones o una pantalla de ajustes vacía solo para parecer nativa no sustituye un valor real para los usuarios.

¿Cómo se responde a App Review en App Store Connect?

Responde en App Store Connect: abre el envío desde el enlace de problemas sin resolver de la app, haz clic en Resolve y después en Reply to App Review. Según la página de ayuda de Apple, para ello necesitas el rol de Account Holder, Admin o App Manager.

1. En Apps, selecciona la app.
2. En la parte superior de la página, haz clic en el enlace que indica que hay problemas sin resolver.
3. En la sección In Progress, haz clic en Resolve junto al envío.
4. Haz clic en Reply to App Review y escribe tu texto.
5. Para incluir capturas o documentos, haz clic en Attach File y después en Reply.

Apple indica que puedes intercambiar mensajes y adjuntar archivos "hasta que vuelvas a enviar la app a App Review", así que manda tus pruebas antes de reenviarla. Mantén la respuesta breve y basada en hechos: di qué cambió, dónde está y cómo verificarlo. No discutas sobre otras apps que parecen hacer lo mismo.

¿Corregir metadatos, subir una nueva build o apelar?

Corrige los metadatos y vuelve a enviar la misma build cuando solo fallaba la información de la ficha. Sube una nueva build cuando haya que cambiar el comportamiento de la app. Apela solo cuando creas que la app ya cumple la directriz.

La guía de apelaciones de Apple te pide "explicar punto por punto cómo tu app cumple" la directriz. También indica que no apeles si ya corregiste los problemas y volviste a enviar la app. Una apelación completa "no garantiza" que se revoque la decisión. Para apps que ya están en la tienda, la política de envíos de corrección de errores (Bug Fix Submissions) de las directrices establece que las correcciones de errores no se retrasarán por infracciones de las directrices "salvo las relacionadas con cuestiones legales o de seguridad".

¿Cómo solucionaron otros desarrolladores rechazos reales del App Store?

En hilos de foros públicos, muchos rechazos por la 2.1 se debían a diferencias entre la configuración del revisor y la del desarrollador: otra red, otro dispositivo u otro estado de permisos. Un rechazo por la 4.2 es un problema de producto, así que los pequeños ajustes rara vez lo resuelven.

Error de inicio de sesión por la 2.1. Un desarrollador en los foros de Apple Developer citó el mensaje "En concreto, no pudimos iniciar sesión debido a un error", aunque la versión publicada y la de TestFlight iniciaban sesión con las mismas credenciales. Otros desarrolladores del hilo contaron soluciones distintas. Uno lo resolvió "cambiando http por https en el servidor web". Otro, tras tres rechazos, añadió un estado de "Comprueba tu conexión" en lugar de un indicador de carga infinito. Un tercero quitó el iPad del destino de despliegue tras cinco rechazos, lo que esquiva el problema eliminando la compatibilidad con iPad.

Cierre inesperado al abrir la app. En el foro de Solar2D, a un desarrollador le dijeron "No pudimos revisar la app porque se cerró inesperadamente al abrirse" en un iPhone 13 mini con iOS 18.3.2. El registro de fallos adjunto mostraba que faltaba la clave NSUserTrackingUsageDescription. El desarrollador confirmó: "Se aprobó después de añadir: NSUserTrackingUsageDescription".

App WebView por la 4.2. Un desarrollador en los foros de Apple Developer informó de un décimo rechazo de una app basada en WebView. El revisor había enviado una captura del menú lateral izquierdo indicando que le faltaba contenido. Las pantallas principales ya eran nativas, pero dos o tres seguían abriendo un WebView. La respuesta marcada como solución procedía de App Review y recomendaba una consulta individual con App Review. El hilo no confirma una aprobación.

La comparación: los casos de la 2.1 se resolvieron reproduciendo las condiciones del revisor y leyendo el registro de fallos. El caso de la 4.2 se estancó porque cada reenvío cambiaba solo una parte de una app que seguía siendo, en esencia, un sitio web.

¿Cómo evitar que se repita el mismo rechazo?

Convierte cada problema resuelto en un punto de tu checklist de lanzamiento y vuelve a probarlo en la build de lanzamiento antes de cada envío. Las directrices de Apple advierten de que la revisión "tardará más" si una app se rechaza repetidamente por la misma infracción de una directriz.

• Elimina la app y luego instala la build de lanzamiento desde cero en un iPhone y un iPad físicos.
• Inicia sesión con la cuenta de revisión en una red sin servidores de desarrollo ni excepciones HTTP.
• Abre cada solicitud de permiso y confirma que existe cada descripción de uso en Info.plist.
• Asegúrate de que cada compra dentro de la app esté enviada, visible y explicada en las notas para la revisión.
• Actualiza las notas para la revisión cada vez que cambie un flujo. No pegues notas de hace seis versiones.

Para problemas de la 2.1, sigue el plan de pruebas de la build de lanzamiento para rechazos por la 2.1 y configura una cuenta de demostración para el revisor. Después repasa el checklist de envío para la próxima build. Si el mensaje de revisión todavía te deja atascado, envíanos los detalles y te ayudaremos a averiguar si lo que falta es el acceso, los metadatos o el código.