Guideline 2.1 App Store: entender y corregir un rechazo

La guideline 2.1 es la regla que tumba más envíos. Apple mismo lo escribe en su página de App Review: en promedio, más del 40 % de los problemas sin resolver tienen que ver con la 2.1, la que cubre los cierres inesperados, el contenido provisional y la información incompleta.

Este artículo trata solo esta regla: qué abarca, sus dos variantes, cómo prueba tu app el revisor y qué responderle, con tres rechazos que recibí en mis propias apps. Para ver el panorama completo de los motivos de rechazo, mejor lee por qué Apple rechaza una app.

¿Qué es la guideline 2.1 App Completeness?

La guideline 2.1 exige que la app que envías a Apple sea una versión final y completa: sin cierres inesperados, sin enlaces rotos, sin texto provisional, con una cuenta de demostración si la app pide iniciar sesión, y con compras dentro de la app visibles y funcionales. Si el revisor no puede recorrer tu app hasta el final, es un rechazo 2.1.

El texto oficial está en las App Review Guidelines, sección 2 "Performance". Se divide en dos apartados.

2.1(a) pide que cada envío sea una versión final, con todos sus metadatos y URL que funcionen. El texto provisional, los sitios vacíos y cualquier contenido temporal tienen que desaparecer antes del envío. La app debe haberse probado en un dispositivo real para detectar bugs y comprobar su estabilidad. Si pide iniciar sesión, das una cuenta de demostración y dejas tu servidor encendido. Un modo demo integrado puede reemplazar esa cuenta, pero solo con la aprobación previa de Apple, y tiene que mostrar todas las funciones de la app. La frase que lo resume todo: "We will reject incomplete app bundles and binaries that crash".

2.1(b) trata de las compras dentro de la app: deben estar completas, actualizadas, visibles para el revisor y funcionar. Si una compra configurada en App Store Connect no se encuentra en la app, tienes que explicar por qué en las notas de revisión.

Lo que cubre la guideline 2.1 en la práctica

En la práctica, un rechazo 2.1 llega por alguna de estas razones:

• Un cierre inesperado. Al abrir la app, después de un permiso denegado, sin conexión. Basta con uno.
• Un enlace roto. Privacidad, términos de uso, soporte: se va a abrir cada URL declarada.
• Una función inaccesible. Un botón que no lleva a ningún lado, una pantalla obligatoria imposible de pasar, un onboarding sin salida. La forma más traicionera: invisible en tu propio teléfono.
• Una cuenta de demostración que falta o que expiró. El revisor se queda atascado en la pantalla de inicio de sesión, o la cuenta que diste ya no funciona, o el servidor está apagado.
• Contenido de relleno. Lorem ipsum, "Próximamente", pantalla vacía, datos de prueba visibles.
• Compras dentro de la app que no se encuentran. La suscripción existe en App Store Connect, pero el revisor no encuentra la pantalla que la vende, o la compra falla en sandbox. Los errores más comunes en la pantalla de pago están en paywall iOS: 7 errores de principiante.

¿2.1 Information Needed o 2.1(a): cuál es la diferencia?

No todos los mensajes de Apple llevan el mismo título, y la diferencia cambia tu respuesta.

"Guideline 2.1 - Information Needed" significa que el revisor no pudo terminar su revisión y te hace una pregunta. Falta un usuario, una explicación, una forma de llegar a una función. Todavía no es la constatación de un bug: es una solicitud. A veces basta una respuesta precisa en App Store Connect. Pero si la pregunta revela un bloqueo real en la app, necesitas un nuevo build.

"Guideline 2.1(a) - Performance - App Completeness" significa que el revisor constató un problema: un cierre inesperado, un bug, una pantalla que no responde. El mensaje suele indicar el dispositivo usado y muchas veces adjunta una captura. Ahí hay que corregir, enviar otro build y luego responder.

Cómo prueba Apple tu app

Ponte en el lugar del revisor. Hay tres puntos que importan.

Prueba en un dispositivo que quizá no tienes. El mensaje de rechazo suele indicar el modelo. La regla 2.4.1 indica que las apps de iPhone deben funcionar en iPad siempre que sea posible, y una app diseñada para iPhone se muestra ahí en modo de compatibilidad, en una ventana con formato de iPhone. Mis rechazos 2.1 recientes venían de un iPad Air: si solo pruebas en tu iPhone, no ves lo que ve el revisor.

Empieza desde un primer arranque. App nueva, sin caché, sin sesión, sin ninguna actualización descargada.

La red tiene que funcionar solo con IPv6. La regla 2.5.5, vecina de la guideline 2.5.4 sobre los modos en segundo plano, exige que la app funcione por completo en una red solo IPv6, y la página de soporte de Apple sobre IPv6 lo convierte en requisito para todas las apps enviadas desde el 1 de junio de 2016. El riesgo viene de una dirección IPv4 escrita a mano en el código: Apple recomienda probar en una red solo IPv6, con los datos móviles desactivados.

Para reproducir estas condiciones antes del envío, TestFlight en varios dispositivos sigue siendo lo más sencillo: mira TestFlight: probar tu app de iPhone.

Tres rechazos que recibí y su causa real

Tres rechazos recientes en mis propias apps, con su causa real.

Solys: una demo de minijuego imposible de ganar en iPad

Solys es mi despertador con minijuegos. El 18 de agosto de 2026 rechazan un build con "2.1 Information Needed": Apple pide una forma de pasar la misión del juego. El revisor estaba probando en un iPad Air, con la app de iPhone en modo de compatibilidad.

La causa real estaba en la demo de minijuego del onboarding. Las alturas de los obstáculos estaban escritas en puntos fijos. Con la altura de tarjeta disponible en el iPad en modo de compatibilidad, el paso quedaba más estrecho que el personaje: la demo era imposible de ganar. Y el botón "Continuar" solo se activaba si ganabas. Sin salida: el revisor no podía ver la app.

La corrección: una geometría proporcional al tamaño medido de la tarjeta, y un enlace "Saltar la demo" que aparece después de perder.

La lección: todo paso que dependa de un desempeño debe tener una salida sin condiciones. Y cada pantalla obligatoria se prueba en la pantalla más pequeña compatible Y en iPad en modo de compatibilidad.

Nolera: una corrección invisible para el revisor

El 17 de septiembre de 2026 rechazan Nolera después de una revisión en iPad Air. El mensaje combinaba la 2.1(a) con otros puntos. La corrección del problema señalado se había entregado por actualización remota (OTA), sin nuevo build.

El problema: en el primer arranque, el revisor ve el código incluido en el build, no la actualización que se descarga después. Para él, la corrección no existía.

La lección: una corrección pensada para la revisión tiene que estar en el binario que envías a Apple.

Clic: la causa no estaba en la app

El 16 de septiembre de 2026 rechazan Clic. La app, en sí, estaba al día. La causa real estaba en otro lado: la política de privacidad publicada en línea no estaba actualizada respecto al proveedor de IA que usaba. Este rechazo tiene más que ver con la privacidad que con la 2.1, pero ilustra lo mismo: las causas reales no siempre son las que el mensaje da a entender.

La lección: revisa lo que está en línea, no lo que está en tu repositorio. Abre cada URL declarada el día del envío.

Qué responder en el Resolution Center

Después de un rechazo, tu envío pasa a "Unresolved Issues" y la conversación con Apple ocurre en la sección App Review de tu app, a la que todavía se le llama Resolution Center. El procedimiento oficial para responder a App Review permite un mensaje de 4000 caracteres como máximo, con un archivo adjunto.

Escribe en inglés, sin adornos. El revisor quiere tres datos: qué bloqueaba, qué cambió y cómo comprobarlo. Esta es la plantilla que uso (reemplaza el número de build y la corrección por los tuyos):

Hello,

Thank you for your review.

Issue: the onboarding game demo could not be completed on iPad
(iPhone app running in compatibility mode), so the user could
not continue.

Fix in build 1.0.3 (42):
- The game layout now scales to the measured screen size.
- A "Skip demo" link appears after a failed attempt, so the
  onboarding can always be completed.

How to verify: launch the app, start the onboarding demo,
lose once, then tap "Skip demo".

A screen recording is attached.

Best regards,

Algunas reglas:

• Responde la pregunta que te hicieron. En un "Information Needed", empieza por la respuesta exacta, no por el contexto.
• Menciona el build y da el camino hasta la pantalla corregida, en tres o cuatro acciones.
• Adjunta una prueba. Un video corto en un dispositivo parecido al del revisor evita otra ida y vuelta.
• Nada de alegatos. La apelación ante el App Review Board existe, pero en un rechazo 2.1 merecido solo alarga la espera. El detalle de los tiempos está en tiempo de revisión del App Store.

Si el motivo sigue sin quedar claro después de leerlo, el proceso completo está en la página app rechazada por Apple.

Notas de revisión y cuenta de demo

La sección App Review Information de tu versión, en App Store Connect, es tu mejor defensa contra la 2.1. Según la referencia oficial de estos campos, contiene:

• Sign-in required: el usuario y la contraseña de una cuenta de demostración. Esta cuenta no debe expirar. Si tu app usa un inicio de sesión de terceros, da las credenciales de ese servicio.
• Notes: hasta 4000 bytes, en el idioma que quieras. Todo lo que ayude a probar.
• Contact: un nombre, un correo y un número en formato internacional.

Lo que siempre pongo en las notas:

1. El camino hasta cada compra dentro de la app, como pide la regla 2.1(b).
2. Las funciones poco evidentes: un gesto, un permiso, un contenido ligado a una hora.
3. El estado de la cuenta de demo: suscrita o no, datos precargados o vacíos.
4. Las limitaciones conocidas: para hardware o un entorno difícil de reproducir, Apple pide estar listo para enviar un video.

Y una regla fuera del formulario: mantén tu servidor encendido durante toda la revisión. Un servidor de pruebas apagado es una cuenta de demo que ya no funciona, o sea, un rechazo 2.1.

La checklist 2.1 antes del envío

La que aplico antes de cada envío, construida a partir de mis rechazos:

• App instalada desde cero en el iPhone compatible más pequeño, el más grande y un iPad en modo de compatibilidad
• Onboarding recorrido completo, fallando a propósito en cada paso que pida un desempeño
• Cada pantalla obligatoria con una salida sin condiciones
• Ninguna corrección pensada para la revisión entregada solo por actualización remota
• App abierta en modo avión y luego en una red solo IPv6
• Cada URL declarada abierta ese mismo día: privacidad, términos, soporte
• Nada de texto provisional, pantallas vacías ni datos de prueba visibles
• Cuenta de demo probada el día del envío, sin fecha de expiración, servidor encendido
• Cada compra dentro de la app encontrada desde la app y probada en sandbox, incluida la restauración
• Notas de revisión que indican dónde están las compras y las funciones poco evidentes

Si es tu primera publicación, todos los pasos previos están en publicar una app en el App Store.

Envía tu expediente con alguien que ya recibió estos rechazos

El Apple Review Kit reúne mi checklist previa al envío, las plantillas de notas para el revisor y skills de Claude Code que revisan tu proyecto antes de que lo envíes.

¿Acabas de recibir un rechazo 2.1? El kit también te ayuda a encontrar la regla citada, lo que pide, y un ejemplo de corrección y de respuesta. Si quieres que revisemos tu expediente juntos desde ya, reserva una hora conmigo, por videollamada.

Nadie puede garantizar que Apple acepte tu app. Lo que sí puedo hacer es ayudarte a evitar los rechazos 2.1 que yo ya pagué con un ciclo de revisión.

¿Todavía no enviaste tu app? El diagnóstico gratuito te manda mi checklist contra rechazos de Apple, regla 2.1 incluida, y te dice qué te falta antes del envío. Si todavía la estás construyendo, la página de inicio muestra cómo crear una app móvil con la revisión en mente desde el principio.

Preguntas frecuentes

¿Qué significa "Guideline 2.1 - Information Needed"?

El revisor no pudo terminar su revisión y te hace una pregunta: un usuario, una explicación, una forma de llegar a una función. Responde con precisión en App Store Connect. Si la pregunta revela un bloqueo real en la app, como en Solys, corrígelo y envía un nuevo build.

¿Hace falta un nuevo build después de un rechazo 2.1?

Para un cierre inesperado, un bug o una pantalla que bloquea, sí: la corrección tiene que estar en el binario. Una actualización remota no basta, porque el revisor ve el código incluido en el primer arranque. Para un simple dato que falta, puede bastar con una respuesta.

Mi app pide iniciar sesión: ¿qué le doy al revisor?

Una cuenta de demostración que no expire, indicada en la sección App Review Information, y un servidor encendido durante toda la revisión. Un modo demo integrado puede reemplazar esa cuenta solo con la aprobación previa de Apple, y tiene que mostrar todas las funciones.

¿Un rechazo 2.1 puede venir de algo que no sea la app?

Sí. Basta una URL rota en la ficha, una cuenta de demo expirada, un servidor apagado o una compra dentro de la app mal configurada. Y a veces, como en Clic, la causa real está en línea y no en el código: revisa todo lo que el revisor puede abrir.