Rechazo de App Store 2.1 (App Completeness): plan de pruebas del build de release antes de reenviar (2026)

Un rechazo de App Store por la 2.1 App Completeness significa que el revisor no pudo usar tu app como lo haría un cliente. Puede que se cerrara inesperadamente, mostrara contenido provisional, lo bloqueara en una pantalla de inicio de sesión u ocultara una compra dentro de la app. La solución rara vez es una sola línea de código. Antes de reenviar, ejecuta un breve plan de pruebas sobre el build de release, con una instalación limpia y las mismas credenciales que das a App Review. Este artículo recorre ese plan y muestra cómo otros desarrolladores solucionaron el mismo rechazo.

¿Qué comprueba la directriz 2.1 App Completeness de App Store?

La directriz 2.1 comprueba que el build que envías es una app terminada y funcional. Necesita metadatos completos, enlaces que funcionen, un inicio de sesión demo, un backend activo y compras dentro de la app que el revisor pueda encontrar y usar.

Las App Review Guidelines de Apple dividen la 2.1 en dos partes. La 2.1(a) dice que los envíos "deben ser versiones finales con todos los metadatos necesarios y URLs plenamente funcionales" y que hay que eliminar el texto provisional y los sitios web vacíos. También indica que pruebes en un dispositivo para detectar errores y problemas de estabilidad, y que "incluyas los datos de una cuenta demo (¡y enciendas tu servicio de backend!) si tu app incluye inicio de sesión". Apple "rechazará paquetes de apps incompletos y binarios que se cierren o presenten problemas técnicos evidentes". La 2.1(b) dice que las compras dentro de la app deben estar "completas, actualizadas, visibles para el revisor y funcionando". Si una compra configurada no se puede encontrar en la app, explica el motivo en tus notas para la revisión.

Este rechazo es habitual. La página Preparing for App Review de Apple dice: "De media, más del 40 % de los problemas sin resolver están relacionados con la directriz 2.1: App Completeness, que abarca cierres inesperados, contenido provisional, información incompleta y más".

¿Por qué probar el build de depuración no detecta los problemas de la 2.1?

Un build de depuración no se comporta como la copia del revisor. El revisor instala un build de release firmado para distribución en un dispositivo limpio, sin sesión guardada y sin atajos de depuración.

Tu simulador ya tiene la sesión iniciada. Tu API local puede apuntar a un servidor de staging que nunca se cae. Los flags de depuración se saltan el paywall y los feature flags están activados por defecto. El revisor no tiene nada de eso. La página de revisión de Apple también pide "probar a fondo en dispositivos con el software más reciente", así que el revisor puede usar una versión de iOS más nueva que la de tu teléfono de pruebas.

TestFlight es lo más parecido que tienes al entorno del revisor. Según la descripción general de TestFlight, puedes añadir hasta 100 testers internos de tu equipo de App Store Connect y hasta 10.000 testers externos. Puedes probar un build durante un máximo de 90 días. Sube exactamente el build que piensas enviar, instálalo desde TestFlight en un dispositivo que nunca haya ejecutado la app y prueba esa copia.

¿Qué debe cubrir un plan de pruebas del build de release antes de reenviar?

Un plan de pruebas del build de release revisa todas las formas en que un revisor nuevo puede quedarse atascado: arranque, permisos, inicio de sesión, backend, contenido, enlaces, compras, fallos de red e iPad. Ejecuta los pasos en orden sobre el build de TestFlight y anota cada resultado para poder citarlo en tus notas para la revisión.

1. Instalación limpia en la última versión de iOS. Borra cualquier copia anterior, instala desde TestFlight y abre la app sin estado guardado. Haz tres arranques en frío y confirma que el onboarding no se cierra.
2. Deniega cada solicitud de permiso una vez. Rechaza notificaciones, ubicación, cámara y rastreo. La app debe seguir llegando a una pantalla utilizable. Confirma también que Info.plist tiene una descripción de uso para cada recurso protegido que usen la app o sus SDKs.
3. Inicia sesión con las credenciales demo exactas. Cópialas de App Store Connect, no de tu gestor de contraseñas. La cuenta debe tener datos realistas, no necesitar verificación por email y no usar autenticación de dos factores vinculada a tu propio teléfono.
4. Confirma que el backend es el de producción y está activo. El build debe apuntar a los endpoints de producción. Los límites de peticiones, las listas de IPs permitidas y el bloqueo geográfico no deben dejar fuera al revisor. La directriz 2.1(a) te dice que enciendas tu servicio de backend.
5. Recorre cada pestaña y pantalla. Busca lorem ipsum, pantallas de "Próximamente", estados vacíos sin explicación, imágenes de prueba y botones que no hacen nada.
6. Toca cada enlace. Incluye la política de privacidad, el soporte, los términos y cualquier web view. Apple dice que "todas las apps deben incluir un enlace al soporte para usuarios con información de contacto actualizada y un enlace a la política de privacidad".
7. Abre cada compra dentro de la app. Inicia sesión con una cuenta nueva. Comprueba que cada producto enviado con la versión aparece con su precio, se puede comprar en el sandbox y que Restaurar compras funciona.
8. Prueba con una red lenta o caída. Activa el modo avión a mitad de un flujo. Un mensaje de error claro está bien. Un indicador de carga que nunca termina, o un cierre, no.
9. Comprueba el iPad si lo admites. Si la app funciona en iPad, ábrela allí y asegúrate de que el diseño no deja atrapado al usuario.

La cuenta demo del paso 3 provoca más rechazos repetidos que cualquier otro paso. Nuestra guía para configurar una cuenta demo para la revisión de App Store explica cómo crear una que dure.

¿Cómo relacionas un mensaje de rechazo 2.1 con una solución?

Para relacionar un rechazo 2.1 con una solución, lee la frase que sigue al número de la directriz. Nombra el síntoma, y cada síntoma apunta a un paso del plan de pruebas.

Supongamos que una app de seguimiento de hábitos se rechaza con el mensaje "We were unable to review the app because it crashed on launch" (no pudimos revisar la app porque se cerró al abrirse). Una segunda nota dice que el revisor no pudo localizar las compras dentro de la app. La tabla siguiente relaciona síntomas habituales con una causa, una prueba y una solución.

Para un método más general de interpretar cualquier mensaje de rechazo, consulta Rechazo de App Store: cómo solucionarlo, directriz por directriz.

¿Cómo fueron los rechazos 2.1 de otros desarrolladores?

Los casos públicos de la 2.1 siguen el mismo patrón. La app funciona en el entorno del desarrollador y falla para el revisor por algo que solo una instalación limpia o el inicio de sesión de un desconocido podría revelar.

• Cierre por falta de una descripción de uso. En los foros de Solar2D, a un desarrollador le dijeron "We were unable to review the app because it crashed on launch" en un iPhone 13 mini con iOS 18.3.2, aunque la app funcionaba en TestFlight. Otro miembro encontró esto en el registro de fallo adjunto: "This app has crashed because it attempted to access privacy-sensitive data without a usage description." (la app se cerró porque intentó acceder a datos sensibles para la privacidad sin una descripción de uso). El desarrollador contó: "Se aprobó después de añadir: NSUserTrackingUsageDescription".
• Inicios de sesión sociales que el revisor no pudo usar. Un desarrollador en los Apple Developer Forums informó de rechazos repetidos por la 2.1 porque los revisores "no pudieron usar los inicios de sesión sociales". Había proporcionado cuentas demo de Apple y Google, pero el inicio de sesión con Apple ID necesitaba un código de verificación enviado al teléfono del desarrollador. El personal de Apple respondió que App Review se pondría en contacto directamente. No se publicó ninguna solución.
• Compras dentro de la app que "no se encontraron en el binario enviado". En un hilo de la comunidad de RevenueCat, rechazaron a un desarrollador porque no se encontró un plan mensual en el binario, aunque las compras en sandbox funcionaban. Un participante contó que un rechazo similar se resolvió respondiendo con un recorrido detallado y capturas de pantalla de cada ruta hasta el paywall. El equipo de RevenueCat recomendó mostrar todos los productos enviados en el paywall predeterminado y mantener los archivos de prueba de StoreKit fuera del esquema de Archive.

En los tres casos, las pruebas del propio desarrollador habían pasado. El fallo solo aparecía desde el punto de partida de un revisor: sin teléfono para la 2FA, sin sesión previa y sin saber dónde estaba el paywall. Ese punto de partida es justo lo que recrea el plan de pruebas anterior.

¿Qué deben decir las notas para App Review después de un rechazo 2.1?

Las notas para la revisión después de un rechazo 2.1 deben incluir credenciales demo que funcionen, enumerar qué cambió desde el build rechazado e indicar exactamente dónde están las compras dentro de la app y cualquier función poco evidente.

La página de revisión de Apple indica que pongas los datos de la cuenta y cualquier configuración especial en la sección App Review Information. Si una función necesita hardware o un entorno difícil de preparar, "prepárate para proporcionar un vídeo de demostración o el hardware". La directriz 2.3.1(a) añade que las funciones nuevas deben describirse "de forma específica" en las notas para la revisión y que "las descripciones genéricas se rechazarán". Una nota breve y estructurada funciona bien:

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

Si obligaciones legales o de seguridad impiden ofrecer una cuenta demo, la directriz 2.1(a) permite un modo demo integrado, pero solo con la aprobación previa de Apple, y ese modo debe mostrar todas las funciones y capacidades de la app. No cambies a un modo demo sin esa aprobación.

¿Cómo reenvías o apelas un rechazo 2.1?

Para reenviar después de un rechazo 2.1, sube o selecciona el build que probaste, responde a App Review en App Store Connect con lo que cambiaste, actualiza las notas para la revisión y vuelve a enviar. Apela solo si crees que el revisor no entendió la app.

1. Comprueba que el número de build asociado a la versión en App Store Connect coincide con el build de TestFlight que probaste.
2. Responde al mensaje de rechazo con un breve resumen de cada corrección. Si el problema es de compras o de navegación, añade instrucciones paso a paso y capturas de pantalla.
3. Actualiza la sección App Review Information con las credenciales y notas vigentes.
4. Envía a revisión. A octubre de 2026, Apple indica que suele revisar "al menos el 50 % de los envíos en menos de 24 horas y el 90 % en menos de 48 horas".

Si crees que Apple se equivocó, la página de App Review te permite apelar ante el App Review Board. Da motivos concretos de por qué la app cumple las directrices y "envía solo una apelación por cada envío que no superó la revisión". Aun así, ante un rechazo 2.1, reproducir el problema en un dispositivo limpio suele ser más rápido que discutir. Si prefieres delegar el reenvío, nuestro servicio de publicación en App Store incluye la preparación para la revisión y la gestión de los comentarios de rechazo en ambas tiendas por $599, sin incluir las cuotas de las cuentas de desarrollador.

Los problemas de la 2.1 suelen reaparecer en actualizaciones posteriores: un nuevo feature flag, una API key rotada o una cuenta demo caducada. Añade este plan de pruebas a tu rutina de lanzamiento junto con la checklist de publicación en App Store. En las actualizaciones, un lanzamiento por fases limita a cuántos usuarios llega un error que se te haya escapado. Para pedir una segunda opinión sobre un build rechazado, escribe a yagyeshsrbobde@gmail.com con el mensaje de rechazo.