iOS 27 le da a Apple, y a una lista creciente de leyes regionales, una forma formal de decirle a tu app la edad de un usuario antes de que recolectes cualquier dato sobre él. Si tu app recolecta algo de menores, y la mayoría de las apps de consumo lo hacen sin pensarlo en esos términos, la forma en que pides consentimiento y documentas qué recolectas tiene que cambiar. No eventualmente. Para una lista creciente de regiones, ya.
Como este es un tema de cumplimiento, una aclaración de entrada: este artículo es una orientación práctica para equipos de marketing y producto, no asesoría legal. Tus obligaciones dependen de dónde estén tus usuarios y qué hace tu app, y un abogado debe validar los detalles específicos. Esta guía mapea lo que introduce iOS 27, qué significa para el tracking y la segmentación que usas hoy, y un checklist para trabajar antes de que el filtro del App Store se endurezca más. Pushwoosh es una plataforma de engagement de clientes, y donde el consentimiento y la recolección de datos tocan tu configuración con nosotros, te lo señalamos puntualmente.
Lo que realmente introduce iOS 27
Dos APIs están en el centro de esto, y trabajan juntas.
La Declared Age Range API deja que tu app pida el rango de edad de un usuario, por ejemplo 13+, 16+ o 18+, sin pedir ni guardar nunca una fecha de nacimiento. Apple entrega el rango; vos recibís una señal, no una fecha. El framework existe desde iOS 26, y con iOS 27 se endurecen los requisitos y la aplicación que lo rodean.
PermissionKit se encarga del lado del consentimiento parental. Cuando tu app hace un cambio significativo que afecta cómo la usa un menor, PermissionKit es el flujo que informa al usuario y, en regiones reguladas, pide la aprobación de un padre o tutor antes de que el menor continúe.
El punto de diseño importante: el sistema te avisa cuándo aplica esto. A través de señales como isEligibleForAgeFeatures y requiredRegulatoryFeatures, el sistema operativo indica si las obligaciones de edad aplican a un usuario dado y si necesitás pedir el rango de edad o el consentimiento parental. No estás adivinando usuario por usuario — la plataforma te entrega la aplicabilidad.
Lo que los titulares de “obligatorio en septiembre” cuentan mal
Vale la pena ser precisos acá, porque la obligación no es un interruptor global único, y “obligatorio en septiembre” no es algo que Apple realmente diga. Hay dos cosas separadas ocurriendo, y la cobertura mediática tiende a colapsarlas en una sola fecha límite.
La primera es el filtro de revisión del App Store. Apple ha ido endureciendo de forma constante lo que tu documentación de privacidad y tu manejo de edad tienen que mostrar, y se espera que las apps con funciones sociales o de contenido generado por usuarios implementen un control de edad visible para el usuario, respaldado por la Declared Age Range API. Esto se endurece a lo largo del ciclo de iOS 27 en vez de activarse una mañana con fecha fija — pero si tu app tiene funciones sociales, tratalo como trabajo para terminar antes de tu próximo release, no después.
La segunda, y la que tiene fechas duras, es la ley regional, y ya está vigente en varios lugares. El propio Apple ata las obligaciones de Declared Age Range a jurisdicciones específicas: las categorías de edad se comparten para las nuevas cuentas de Apple en Utah desde el 6 de mayo de 2026 y en Luisiana desde el 1 de julio de 2026, y Apple empezó a bloquear descargas 18+ en Australia, Brasil y Singapur el 24 de febrero de 2026. Otras leyes tienen sus propios cronogramas, algunas ya vigentes, otras pospuestas. Las señales regulatorias del sistema existen precisamente porque la respuesta a “¿tengo que hacer esto para este usuario?” depende de su región y del estado actual de la ley en esa región.
La lectura práctica: si tenés funciones sociales o UGC, o recolectás datos de menores en cualquier región regulada, esto es trabajo activo, no un ítem futuro. Si ninguna de las dos te aplica todavía, se sigue esperando que mantengas tu documentación de privacidad al día, y el mapa regional se está expandiendo, así que construir la capacidad ahora sale más barato que adaptarla después bajo presión de una fecha límite.
Por qué esto recae en marketing, no solo en legal
La verificación de edad parece una tarea legal-y-de-ingeniería hasta que seguís a dónde llega. Ahí cae de lleno sobre cómo trackeás y segmentás.
Si recolectás identificadores publicitarios, disparás eventos de comportamiento automáticos o armás segmentos sobre actividad in-app, una señal de edad cambia qué te está permitido recolectar y sobre quién. Un usuario en un rango de edad protegido no es alguien a quien podés inscribir en silencio en el mismo tracking de comportamiento y recolección de ID publicitario que a un adulto. En el momento en que el sistema operativo te puede decir que un usuario es menor en una región regulada, “trackeamos a todos igual” deja de ser un default defendible.
Este es también el momento para cerrar una brecha que muchas apps arrastran: manejo poco claro o sin documentar de los identificadores publicitarios (IDFA en iOS, GAID en Android). Si tu documentación de datos no dice claramente qué identificadores publicitarios recolectás y por qué, esa brecha ya era un riesgo. A medida que el filtro de revisión se endurece durante el ciclo de iOS 27, se convierte en un riesgo de rechazo. Arreglar la historia de recolección de edad y la documentación de ID publicitario en la misma pasada es el movimiento eficiente, porque viven en las mismas declaraciones de privacidad.
Tu checklist de cumplimiento
Trabajalo con tus socios legales y de ingeniería:
- Mapeá dónde están tus menores. Identificá en qué regiones operás que ya tienen leyes de verificación de edad vigentes, y si tu app tiene funciones sociales o UGC que disparan el filtro del App Store sin importar la región.
- Adoptá las señales de aplicabilidad. Usá las señales del sistema operativo que te dicen si las obligaciones de edad aplican a un usuario dado, en vez de construir tus propias conjeturas. Dejá que la plataforma te diga cuándo pedir un rango de edad o consentimiento.
- Pedí el rango de edad, no la fecha de nacimiento. Donde necesites una señal de edad, usá la Declared Age Range API para recibir un rango y nunca recolectar ni guardar una fecha de nacimiento que después tendrías que proteger.
- Conectá el consentimiento parental para cambios significativos. Si menores usan tu app, asegurate de tener el flujo de consentimiento por cambio significativo para las regiones que lo exigen.
- Segmentá el tracking por rango de edad. Asegurate de que los usuarios en rangos de edad protegidos queden excluidos de la recolección de ID publicitario y del tracking de comportamiento que no está permitido para menores. Esto es una configuración de recolección de datos y consentimiento, no una revisión manual usuario por usuario.
- Actualizá tu documentación de privacidad. Poné al día tus declaraciones de privacidad del App Store, y ya que estás, cerrá la brecha de documentación de ID publicitario para que el manejo de IDFA y GAID quede claramente declarado. Es lo primero que revisa el filtro del App Store.
- Revisá tus textos de consentimiento. Asegurate de que el lenguaje de consentimiento que ve un menor o tutor coincida con lo que realmente recolectás, en el mismo espíritu que tus prácticas de consentimiento GDPR.
Manejá la recolección de datos sensible a la edad con Pushwoosh
Pushwoosh te da gestión de consentimiento y controles de recolección de datos para segmentar el tracking por rango de edad, excluir a usuarios protegidos de recolecciones en las que no deberían estar, y mantener tu manejo de ID publicitario documentado y limpio. Contamos con certificación SOC 2 Type I e ISO 27001:2022, cumplimiento GDPR y HIPAA, y centros de datos en la UE y EE. UU. El trabajo de cumplimiento nunca es de esfuerzo cero, pero el lado de los datos no debería ser la parte difícil.
