Si publicas una app en Google Play o la App Store, la verificación de edad ha dejado de ser un problema "de las redes sociales" para convertirse en infraestructura que tarde o temprano te va a tocar. Google y Apple ya exponen APIs para que tu app conozca el rango de edad del usuario sin pedir la fecha de nacimiento, y la Unión Europea está empujando su propia app de verificación de edad. La respuesta corta: casi nadie tiene que integrarlo hoy, pero conviene diseñar el producto sabiendo que llega. Te contamos qué ha pasado, a quién afecta de verdad y qué haríamos nosotros.

Qué ha pasado

Tres frentes se han movido casi a la vez.

Google — Play Age Signals API (beta). Es una API cliente de Google Play que devuelve señales de edad: estado de verificación, nivel de supervisión y un rango de edad (por defecto 0-12, 13-15, 16-17 y 18+), sin entregar la fecha de nacimiento ni documentos. Empezó a devolver señales en Brasil (17 de marzo de 2026, por el Digital ECA) y en Texas para cuentas creadas después del 28 de mayo (ley SB2420), y su despliegue se amplía a Australia y Canadá a mediados de agosto, con disponibilidad global prevista para final de año. Google marca una línea roja importante: los datos no pueden usarse para publicidad, marketing, perfilado ni analítica; solo para adaptar la experiencia a la edad.

Apple — Declared Age Range API. Disponible en iOS 26, iPadOS 26 y macOS 26 o superior, permite pedir una categoría de edad (menor de 13, 13-15, 16-17, mayor de 18) sin solicitar la fecha de nacimiento. Apple la fue activando por jurisdicción para cuentas nuevas: Texas (1 de enero de 2026), Utah (6 de mayo) y Louisiana (1 de julio), además de mercados como Brasil, Australia y Singapur. Las últimas capacidades llegan en las betas de iOS 26.2, con sandbox para probar el flujo.

Unión Europea — app de verificación de edad. La Comisión presentó en abril de 2026 una app europea de verificación de edad "técnicamente lista", con un piloto en países como Dinamarca, Francia, Grecia, Italia, España, Chipre e Irlanda, pensada para integrarse en las carteras EUDI Wallet. La Comisión urge su despliegue antes de que acabe 2026 en el marco del artículo 28 de la DSA, y el 22 de julio se registró una iniciativa ciudadana pidiendo hacerla legalmente obligatoria. Es decir: además de las APIs de las tiendas, viene una vía europea con identidad soberana.

Qué implica para tu producto

Lo relevante no es el titular regulatorio, sino tres decisiones concretas de producto:

  • Gating por edad como requisito, no como feature. Si tu app tiene contenido, chat, compras o UGC que podría requerir restricción por edad en alguna jurisdicción, el flujo de onboarding deja de ser solo "email y contraseña". Hay que contemplar un punto donde la app pregunta la señal de edad y ramifica la experiencia.
  • Fragmentación por plataforma y país. Play Age Signals y Declared Age Range no son la misma API, ni devuelven exactamente los mismos rangos, ni se activan en los mismos países a la vez. Si operas en varios mercados, necesitas una capa de abstracción propia que normalice "menor / adolescente / adulto" y decida el comportamiento, en lugar de esparcir if de plataforma por toda la base de código.
  • Privacidad como restricción de diseño. Ambas APIs están diseñadas para minimizar datos (rango, no fecha). Ese es precisamente el punto delicado con el RGPD: la tentación de guardar la señal, cruzarla o usarla para segmentar. Google lo prohíbe explícitamente y la lógica del RGPD (minimización, limitación de finalidad) va en la misma dirección. La señal de edad se consume, se usa para adaptar la experiencia y no se convierte en un dato de perfilado.

En Flutter, esto se traduce en un plugin que hable con la API nativa de cada plataforma (vía platform channels con Pigeon para tipado seguro) y exponga un contrato único a la capa de dominio. En backend, en no persistir la señal salvo que exista base legal para ello.

A quién afecta y a quién no

Seamos honestos, porque aquí hay mucho ruido:

  • Te afecta ya (o muy pronto) si tu app cae bajo una ley de assurance activa (varios estados de EE. UU., Brasil, Australia) o si tratas con menores, contenido sensible, apuestas, dating o social. Aquí no es opcional: es cumplimiento.
  • Te afecta en diseño, no en integración inmediata, si eres una app de productividad, fintech B2B, salud profesional o herramienta interna. Probablemente no tengas que integrar nada este trimestre, pero sí evitar arquitecturas de onboarding que hagan carísimo añadir gating por edad más adelante.
  • No te afecta apenas si tu app no distingue experiencia por edad en ninguna jurisdicción donde operas. Integrar age assurance "por si acaso" solo añade superficie de datos sensibles y complejidad. No lo hagas.

Nuestra recomendación

Nosotros no integraríamos Play Age Signals ni Declared Age Range de forma preventiva en la mayoría de proyectos. Están en beta o en despliegue por fases, cambian de rango y de país cada pocas semanas, y adoptarlas hoy es firmar deuda de mantenimiento sin una obligación legal que lo justifique.

Lo que sí haríamos —y hacemos con clientes— es dejar el onboarding preparado: un punto de extensión donde inyectar la señal de edad el día que haga falta, una capa de abstracción propia sobre las APIs de plataforma, y una política clara de "esta señal no se persiste ni se usa para marketing". Con eso, pasar de cero a cumplir en un mercado nuevo es una tarea de días, no una refactorización.

Si estás rediseñando el registro de tu app o entrando en un mercado con leyes de age assurance, es buen momento para revisar el flujo antes de escribir código. Es exactamente el tipo de decisión que abordamos en un product discovery y desde nuestra experiencia con RGPD en apps. Si quieres una segunda opinión técnica sobre cómo encaja en tu producto, hablemos.