Guideline 5.1.1: entender y corregir un rechazo de App Store

La guideline 5.1.1 es la regla de Apple sobre la recopilación y el almacenamiento de datos. En mis tres rechazos de esta familia, la causa fue una de estas dos diferencias: lo que la app hacía con los datos no coincidía con lo que estaba declarado, o la solicitud de permiso empujaba al usuario a decir que sí.

Este artículo trata solo esta regla: sus incisos, lo que reviso antes del envío y qué corregir, con tres rechazos que recibí en mis propias apps. Para ver el panorama completo de todos los motivos, mejor lee por qué Apple rechaza una app.

¿Qué es la guideline 5.1.1?

La guideline 5.1.1, "Data Collection and Storage", define lo que una app debe cumplir en cuanto toca datos personales: una política de privacidad completa, consentimiento antes de recopilar, solicitudes de permiso honestas y una cuenta que se pueda eliminar. Se aplica a todas las apps, incluso a las que casi no recopilan nada.

El texto oficial está en las App Review Guidelines, sección 5 "Legal", apartado 5.1 "Privacy". El mensaje de Apple suele citar un inciso concreto, entre paréntesis: 5.1.1(i), 5.1.1(iv), 5.1.1(v). Ese inciso es el que te dice dónde buscar.

Los cinco incisos de la 5.1.1 que debes conocer primero

Inciso	Lo que exige Apple	El rechazo típico
5.1.1(i) Privacy Policies	Política completa y enlazada	Ausente o incompleta
5.1.1(ii) Permission	Consentimiento antes de recopilar	Texto de permiso vago
5.1.1(iii) Data Minimization	Solo los datos necesarios	Acceso completo a las fotos
5.1.1(iv) Access	No presionar para aceptar	Pantalla que presiona a aceptar
5.1.1(v) Account Sign-In	No imponer una cuenta	Inicio de sesión obligatorio

Tres aclaraciones. La política de privacidad está enlazada en App Store Connect y dentro de la app. Dice qué datos se recopilan, cómo y para qué, confirma que los terceros que los reciben ofrecen la misma protección y explica cómo retirar el consentimiento o pedir que se borren los datos. Una función de pago no puede depender de un acceso a datos que el usuario es libre de rechazar. Y una cuenta creada en la app debe poder eliminarse desde la app.

La regla tiene otros incisos, del (vi) al (x), sobre casos más particulares como los sectores regulados o la recopilación de datos personales.

Las tres cosas que comparo antes del envío

No tengo el manual del revisor. Esto es lo que yo mismo comparo antes de cada envío, porque mis rechazos vinieron de una diferencia entre estos elementos:

• lo que dice la política publicada, en la URL declarada en App Store Connect;
• lo que la app hace de verdad, pantalla por pantalla, incluida cada solicitud de permiso;
• lo que está declarado en la ficha, en la parte sobre la privacidad de la app (App Privacy Details).

También pruebo cada pantalla de permiso cerrando la app y volviéndola a abrir. Es la causa que identifiqué en mi segundo rechazo de Nolera.

Tres rechazos 5.1.1 que recibí, y su causa real

Clic: la política publicada era la versión vieja

Clic convierte un producto en slides listas para publicar, con IA. El 16 de septiembre de 2026, Apple rechaza la app citando la 5.1.1(i) y la 5.1.2(i). La pantalla de consentimiento para la IA sí estaba en la app. El problema estaba fuera de la app: la política de privacidad publicada en el sitio era la versión vieja. La nueva existía, pero no se había subido.

La corrección: política completa publicada, un resumen en inglés agregado para el revisor y notas de revisión actualizadas. No hice un build nuevo: reenvié el mismo envío.

La lección: Apple lee lo que está en línea, no lo que está en tu repositorio. El día del envío, abre la URL de tu política y busca el nombre de cada servicio de terceros que usa tu app.

Nolera: un botón "Allow" antes de la solicitud del sistema

Nolera es mi app de clóset. El 17 de septiembre de 2026, tras una revisión en un iPad Air, Apple cita la 5.1.1(iv). Antes de la solicitud de acceso a la cámara, la app mostraba una pantalla de explicación con un botón "Allow the camera".

Las reglas de diseño de Apple son precisas en este punto. Una pantalla propia colocada antes de una solicitud del sistema debe tener un solo botón, que abre esa solicitud. Apple recomienda un término como "Continue" o "Next", y no "Allow": un botón que se parece al del sistema lleva a tocar después el verdadero "Allow" sin haberlo querido.

Esta regla apunta a las pantallas colocadas antes de una solicitud del sistema: cámara, micrófono, ubicación, contactos, calendario, rastreo. Deja una excepción, para un consentimiento exigido por la ley.

La corrección: el botón se llama "Continue", en los 8 idiomas de la app.

La lección: una pantalla que prepara un permiso explica. No decide en lugar del usuario.

Nolera, segundo rechazo: la pantalla "cámara denegada" aparecía antes de la solicitud

Al reenviarla, Nolera es rechazada por segunda vez el 22 de septiembre de 2026, otra vez por la 5.1.1(iv), esta vez en un iPad Pro de 11 pulgadas. Apple señala dos puntos: un envío a Ajustes antes de la solicitud de acceso, y una pantalla de la que se podía salir sin ver esa solicitud.

La causa que identifiqué: un caso que no había probado. La pantalla de captura mostraba su panel "cámara denegada", con el enlace a Ajustes y una alternativa, en cuanto el acceso no estaba concedido. Incluso cuando nunca se había pedido. En el recorrido normal, la pantalla de explicación aparecía antes y todo iba bien. Pero si cerrabas la app a la mitad y la volvías a abrir, retomabas directamente en la captura, sin haber visto la solicitud del sistema.

La corrección: mientras iOS todavía pueda hacer la pregunta, la pantalla lanza ella misma la solicitud del sistema. El panel "cámara denegada" solo aparece después de un rechazo real. Esta corrección necesitó un build nuevo, porque el revisor prueba el código incluido en la app.

La lección: "nunca solicitado" y "denegado" son dos estados distintos. Prueba cada pantalla de permiso volviendo a ella después de cerrar la app, no solo en el orden del recorrido.

5.1.1 e IA: lo que agrega la 5.1.2(i)

En Clic, Apple citó la 5.1.2(i) además de la 5.1.1. Esta regla pide indicar claramente dónde se comparten los datos personales con terceros, y menciona expresamente la IA de terceros ("third-party AI"). También pide un permiso explícito antes de compartirlos.

Mi práctica desde ese rechazo: tres cosas coherentes entre sí.

• Una pantalla de consentimiento en la app, antes del primer envío, que dice a qué servicio van los datos y cuáles.
• La misma información en la política de privacidad publicada.
• La misma información en las declaraciones de privacidad de la ficha.

El detalle de lo que debe contener la política está en política de privacidad de una aplicación.

Qué responder a Apple después de un rechazo 5.1.1

La conversación ocurre en la sección App Review de tu app, en App Store Connect. El procedimiento oficial para responder a App Review es el mismo que para las demás reglas. Escribe en inglés, con sobriedad: qué fallaba, qué cambió y cómo verificarlo. 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 custom screen shown before the camera permission
request used an "Allow" button, and the "camera denied" panel
could appear before the system alert had ever been shown.

Fix in build X:
- The custom screen now has a single "Continue" button that
  opens the system alert.
- The "camera denied" panel only appears after the user has
  actually denied access in the system alert.

How to verify: delete the app, install this build, launch it
and go to the photo step. The system alert appears first.

Best regards,

Hay dos casos:

• La causa está en línea (política, página de soporte, declaraciones de la ficha): corriges, respondes, y el mismo envío puede volver a revisión sin build nuevo.
• La causa está en la app (pantalla, botón, orden de las solicitudes): necesitas un build nuevo. Una actualización remota no basta, como explico en la guía sobre la guideline 2.1.

La checklist 5.1.1 antes del envío

• La URL de tu política de privacidad abre, y la página publicada es la última versión.
• La política nombra cada servicio de terceros que recibe datos, IA incluida. Es mi regla, más estricta que el texto de Apple.
• Las declaraciones de privacidad de tu ficha dicen lo mismo que la política y que el privacy manifest del build.
• Cada texto de permiso explica el uso en una frase precisa.
• No se pide ningún permiso al iniciar si la app puede funcionar sin él. Misma lógica para los modos en segundo plano: ningún modo declarado sin una función que lo use.
• Una pantalla propia antes de una solicitud tiene un solo botón, "Continue", que abre la solicitud del sistema.
• Quien rechaza un permiso puede seguir de otra forma, o entiende lo que pierde.
• La pantalla "acceso denegado" solo aparece después de un rechazo real. La probaste cerrando y volviendo a abrir la app.
• La app se puede usar sin cuenta cuando la cuenta no es indispensable.
• Una cuenta creada en la app puede eliminarse desde la app: la receta está en eliminación de cuenta en iOS.
• Todo está probado también en iPad: mis dos rechazos 5.1.1 de Nolera se detectaron en iPad.

Corrige tu rechazo con alguien que ya recibió ese mismo

Si tu app acaba de ser rechazada por la 5.1.1, el Apple Review Kit te ayuda a encontrar la regla citada, lo que pide y un ejemplo de corrección y de respuesta. Si quieres que revisemos tu caso juntos desde ya, reserva una hora conmigo, por videollamada. El proceso completo también está en la página aplicación rechazada por Apple.

Si estás preparando tu primer lanzamiento, haz el diagnóstico gratuito: ordena tus pasos y te envía mi checklist antirrechazo de Apple, privacidad incluida. Para crear tu aplicación móvil pensada para la revisión desde el principio, el recorrido en cuatro etapas del iOS Kit va desde la idea hasta el envío a Apple.

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

Preguntas frecuentes

¿Qué significa "Guideline 5.1.1 - Legal - Privacy - Data Collection and Storage"?

Es el título completo de la regla en el mensaje de Apple. Señala un problema con datos personales: política de privacidad incompleta, solicitud de permiso considerada insistente o cuenta imposible de eliminar. El inciso entre paréntesis, por ejemplo 5.1.1(iv), indica cuál.

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

No siempre. Si la causa está en línea, como una política de privacidad desactualizada, corriges la página, respondes a Apple y el envío vuelve a revisión sin build nuevo. Si la causa es una pantalla o un botón de la app, necesitas un build nuevo.

¿Se puede mostrar una pantalla de explicación antes de una solicitud de permiso?

Sí, Apple lo permite cuando de verdad es útil. En ese caso la pantalla tiene un solo botón, que abre la solicitud del sistema, con un término como "Continue" o "Next". Nada de botón "Allow", ni botón para cerrar u omitir, salvo un consentimiento exigido por la ley.

Mi app usa una IA externa: ¿qué tengo que declarar?

La guideline 5.1.2(i) pide indicar dónde se comparten los datos con terceros, IA incluida, y obtener un permiso explícito antes. Yo la aplico en tres lugares: una pantalla de consentimiento en la app, la política de privacidad publicada y las declaraciones de privacidad de la ficha. En Clic, Apple citó esta regla junto con la 5.1.1.

¿La cuenta es obligatoria para cumplir la 5.1.1?

No, es al revés. Si tu app no tiene una función que de verdad dependa de una cuenta, Apple pide que se pueda usar sin iniciar sesión. Y si permite crear una cuenta, también debe permitir eliminarla desde la app.