O iOS 27 dá à Apple, e a uma lista crescente de leis regionais, uma forma formal de informar ao seu app a idade de um usuário antes de você coletar qualquer dado sobre ele. Se seu app coleta qualquer coisa de menores, e a maioria dos apps de consumo faz isso sem nem pensar nesses termos, a forma como você pede consentimento e documenta o que coleta precisa mudar. Não eventualmente. Para uma lista crescente de regiões, agora — e o Brasil está literalmente nessa lista.
Como este é um tema de conformidade, um aviso antes de tudo: este artigo é uma orientação prática para times de marketing e produto, não é aconselhamento jurídico. Suas obrigações dependem de onde estão seus usuários e do que seu app faz, e um advogado precisa validar os detalhes específicos. Este guia mapeia o que o iOS 27 introduz, o que isso significa para o tracking e a segmentação que você usa hoje, e traz um checklist para você trabalhar antes que o filtro da App Store fique mais rígido. A Pushwoosh é uma plataforma de engajamento de clientes, e onde consentimento e coleta de dados tocam sua configuração conosco, apontamos exatamente onde.
O que o iOS 27 realmente introduz
Duas APIs estão no centro disso, e elas funcionam juntas.
A Declared Age Range API permite que seu app peça a faixa etária de um usuário, por exemplo 13+, 16+ ou 18+, sem nunca pedir ou guardar uma data de nascimento. A Apple entrega a faixa; você recebe um sinal, não uma data. O framework existe desde o iOS 26, e o iOS 27 é onde os requisitos e a fiscalização em volta disso ficam mais rígidos.
O PermissionKit cuida do lado do consentimento parental. Quando seu app faz uma mudança significativa que afeta como um menor o usa, o PermissionKit é o fluxo que informa o usuário e, em regiões regulamentadas, pede a aprovação de um pai, mãe ou responsável antes que o menor continue.
O ponto de design importante: o sistema avisa quando isso se aplica. Por meio de sinais como isEligibleForAgeFeatures e requiredRegulatoryFeatures, o sistema operacional indica se obrigações de idade se aplicam a um determinado usuário e se você precisa pedir a faixa etária ou o consentimento parental. Você não está chutando usuário por usuário — a plataforma te entrega a aplicabilidade pronta.
O que as manchetes de “obrigatório em setembro” erram
Vale a pena ser preciso aqui, porque a obrigação não é um interruptor global único, e “obrigatório em setembro” não é algo que a Apple realmente diz. Existem duas coisas separadas acontecendo, e a cobertura da imprensa tende a juntar tudo numa única data limite.
A primeira é o filtro de revisão da App Store. A Apple vem apertando gradualmente o que sua documentação de privacidade e seu tratamento de idade precisam mostrar, e apps com recursos sociais ou de conteúdo gerado pelo usuário devem implementar um controle de idade visível ao usuário, apoiado na Declared Age Range API. Isso aperta ao longo de todo o ciclo do iOS 27, em vez de ligar numa manhã com data marcada — mas se seu app tem recursos sociais, trate isso como trabalho para terminar antes do seu próximo release, não depois.
A segunda, com datas fixas, é a lei regional, e ela já está valendo em vários lugares. A própria Apple vincula as obrigações de Declared Age Range a jurisdições específicas: as categorias de idade são compartilhadas para novas contas Apple em Utah desde 6 de maio de 2026 e na Louisiana desde 1º de julho de 2026, e a Apple começou a bloquear downloads 18+ na Austrália, no Brasil e em Cingapura em 24 de fevereiro de 2026. Outras leis seguem seus próprios calendários, algumas já em vigor, outras adiadas. Os sinais regulatórios do sistema existem exatamente porque a resposta a “eu preciso fazer isso para este usuário” depende da região dele e do estado atual da lei naquela região.
A leitura prática: se você tem recursos sociais ou UGC, ou coleta dados de menores em qualquer região regulamentada — e o Brasil é uma delas —, isso é trabalho corrente, não um item futuro. Se nenhum dos dois se aplica ainda a você, manter a documentação de privacidade em dia continua sendo esperado, e o mapa regional está se expandindo, então construir essa capacidade agora sai mais barato do que adaptar depois sob pressão de prazo.
Por que isso cai no colo do marketing, não só do jurídico
Verificação de idade parece tarefa de jurídico-e-engenharia até você seguir aonde ela chega. Aí ela cai direto em como você faz tracking e segmentação.
Se você coleta identificadores publicitários, dispara eventos comportamentais automáticos ou monta segmentos com base em atividade no app, um sinal de idade muda o que você pode coletar e sobre quem. Um usuário numa faixa etária protegida não é alguém que você pode inscrever discretamente no mesmo tracking comportamental e coleta de ID publicitário que um adulto. No momento em que o sistema consegue dizer que um usuário é menor numa região regulamentada, “rastreamos todo mundo do mesmo jeito” deixa de ser um padrão defensável.
Esse também é o momento de fechar uma lacuna que muitos apps carregam: tratamento pouco claro ou não documentado de identificadores publicitários (IDFA no iOS, GAID no Android). Se sua documentação de dados não diz claramente quais identificadores publicitários você coleta e por quê, essa lacuna já era um risco. Com o filtro de revisão apertando ao longo do ciclo do iOS 27, ela vira risco de rejeição. Resolver a história de coleta de idade e a documentação de ID publicitário na mesma passada é o movimento eficiente, já que os dois vivem nas mesmas declarações de privacidade.
Seu checklist de conformidade
Trabalhe isso com seus parceiros jurídico e de engenharia:
- Mapeie onde estão seus usuários menores de idade. Identifique em quais regiões você opera que já têm leis de verificação de idade em vigor, e se seu app tem recursos sociais ou UGC que disparam o filtro da App Store independente da região.
- Adote os sinais de aplicabilidade. Use os sinais do sistema operacional que indicam se obrigações de idade se aplicam a um determinado usuário, em vez de criar suas próprias suposições. Deixe a plataforma te dizer quando pedir uma faixa etária ou consentimento.
- Peça a faixa etária, não a data de nascimento. Onde você precisar de um sinal de idade, use a Declared Age Range API para receber uma faixa e nunca coletar nem guardar uma data de nascimento que depois você teria que proteger.
- Conecte o consentimento parental para mudanças significativas. Se menores usam seu app, garanta que o fluxo de consentimento por mudança significativa esteja implementado para as regiões que exigem isso.
- Segmente o tracking por faixa etária. Garanta que usuários em faixas etárias protegidas fiquem excluídos da coleta de ID publicitário e do tracking comportamental não permitido para menores. Isso é uma configuração de coleta de dados e consentimento, não uma revisão manual usuário por usuário.
- Atualize sua documentação de privacidade. Deixe suas declarações de privacidade da App Store em dia e, já que está nisso, feche a lacuna de documentação de ID publicitário para que o tratamento de IDFA e GAID fique claramente declarado. É o primeiro item que o filtro de revisão checa.
- Revise seus textos de consentimento. Garanta que a linguagem de consentimento que um menor ou responsável vê corresponda ao que você realmente coleta, no mesmo espírito das suas práticas de consentimento GDPR.
Trate a coleta de dados sensível à idade com a Pushwoosh
A Pushwoosh te dá gestão de consentimento e controles de coleta de dados para segmentar o tracking por faixa etária, excluir usuários protegidos de coletas em que eles não deveriam estar, e manter seu tratamento de ID publicitário documentado e limpo. Temos certificação SOC 2 Type I e ISO 27001:2022, conformidade com GDPR e HIPAA, e data centers na UE e nos EUA. O trabalho de conformidade nunca é de esforço zero, mas o lado dos dados não precisa ser a parte difícil.
