O que o App Tracking Transparency Efetivamente Regula

O ATT é uma barreira de permissão que a Apple aplica no iOS e iPadOS. Quando uma aplicação pretende aceder ao Identificador para Anunciantes (IDFA) do dispositivo ou realizar rastreamento que liga o utilizador a aplicações e sites de outros operadores, tem de chamar requestTrackingAuthorization e apresentar um pedido do sistema que solicita ao utilizador que permita ou recuse o rastreamento. A resposta do utilizador é binária, persistente até que a altere nas Definições, e visível para a aplicação através da API trackingAuthorizationStatus.

A Definição de Rastreamento da Apple

A orientação para programadores da Apple define o rastreamento de forma específica e restrita: associar dados de utilizador ou dispositivo recolhidos da sua aplicação com dados de utilizador ou dispositivo recolhidos das aplicações, sites ou propriedades offline de outras empresas para publicidade dirigida ou medição, ou partilhar dados de utilizador ou dispositivo com corretores de dados. A definição exclui deliberadamente a utilização de dados de primeira parte dentro da aplicação, análises agregadas anónimas e processamento para prevenção de fraude ou conformidade jurídica — essas atividades não requerem um pedido ATT independentemente de o utilizador o ter concedido.

O que o ATT Não Faz

O ATT não é um sistema de gestão de consentimento no sentido do GDPR. Não recolhe preferências de finalidade detalhadas, não regista um recibo de consentimento com controlo de versões de política, não propaga sinais para fornecedores web dentro de uma WKWebView, e não satisfaz o requisito de base jurídica para armazenar ou ler cookies no dispositivo de um utilizador. Um editor que trata o pedido ATT como a sua postura de conformidade completa para uma aplicação híbrida está a uma carta de regulador de distância de uma multa, porque o carregamento de cookies dentro da visualização web é um evento separado ao abrigo do ePrivacy e necessita da sua própria camada de consentimento.

Como o GDPR e o ePrivacy se Aplicam Dentro de uma WKWebView

A visualização web dentro de uma aplicação híbrida não está magicamente isenta das regras que se aplicam a um navegador de secretária. No momento em que a WKWebView lê ou escreve um cookie que não é estritamente necessário, o ePrivacy é ativado. No momento em que a WKWebView envia um pedido de análise ou publicidade que transporta dados pessoais, o GDPR é ativado. O contentor da Apple não altera a análise — o que muda é a superfície de implementação, porque o banner de consentimento tem de renderizar dentro da visualização web e o estado de consentimento tem de ser visível para o código nativo que pode também estar a ler os mesmos dados.

O Banner Dentro da Visualização Web

O padrão standard é renderizar um banner CMP dentro da WKWebView da mesma forma que num site. O banner define cookies no armazenamento de cookies da visualização web, envia um evento de atualização de consentimento para o contexto JavaScript da página, e atualiza uma máquina de estados do Google Consent Mode v2 que as etiquetas de análise e publicidade da página leem. A implementação não é diferente de um CMP web normal — o que é diferente é que o armazenamento de cookies está limitado à WKWebView e não é visível para outras aplicações ou para o Safari, o que é útil para isolamento mas não é útil se o editor também gere um site onde o utilizador já consentiu.

Partilhar o Consentimento entre a Visualização Web e a Camada Nativa

O problema mais difícil é a ponte entre a WKWebView e a camada nativa. A camada nativa pode ter o seu próprio SDK de análise que lê o IDFA depois de o utilizador ter concedido o ATT, enquanto a visualização web tem o seu próprio banner de consentimento que o utilizador pode ou não ter aceite. Se o utilizador conceder o ATT mas recusar o consentimento de publicidade na visualização web, o SDK nativo ainda pode ler o IDFA, mas as etiquetas da visualização web não devem fazê-lo. Se o utilizador recusar o ATT mas aceitar o consentimento de publicidade da visualização web, o SDK nativo está bloqueado, mas as etiquetas da visualização web ainda devem ser ativadas — embora o identificador baseado em IDFA do SDK nativo obviamente não possa atravessar a ponte. O padrão mais limpo é uma única fonte de verdade — o CMP — exposta através de uma ponte JavaScript que a camada nativa lê no início da aplicação e a cada alteração de consentimento, com um pedido ATT paralelo que se subordina à decisão de publicidade do CMP em vez de perguntar novamente.

A Camada CPRA e dos Estados dos EUA

Para os editores dos EUA, o quadro tem uma terceira camada. O CPRA, mais o conjunto de leis estaduais que seguiram a Virgínia, o Colorado, Connecticut e o Utah, tratam o IDFA da mesma forma que os cookies web — ambos são informações pessoais cuja venda ou partilha desencadeia um direito de opt-out. O cabeçalho Global Privacy Control que os navegadores web enviam é o sinal voltado para o consumidor, e o Multi-State Privacy Agreement (MSPA) do IAB com o US Privacy String associado é o sinal voltado para o editor. Uma aplicação híbrida lançada nos EUA precisa de expor um link para «Não Vender nem Partilhar as Minhas Informações Pessoais» dentro da própria aplicação, encaminhar o opt-out resultante tanto para o CMP da visualização web como para o SDK de medição da camada nativa, e respeitar qualquer cabeçalho GPC de entrada que chegue à visualização web a partir de um link de profundidade.

Crianças e COPPA em Aplicações Híbridas

Se a aplicação tiver classificação etária para crianças ou houver alguma expectativa razoável de utilizadores menores de idade, o COPPA nos EUA e as disposições GDPR-K na UE impõem restrições adicionais para além do ATT e do consentimento standard. O IDFA não deve ser solicitado de todo para contas de crianças, o consentimento de publicidade da visualização web deve ser definido por defeito como recusado, e qualquer SDK de terceiros na camada nativa deve ser confirmado como compatível com o COPPA antes do lançamento. A revisão da App Store rejeita aplicações classificadas para crianças que mostram o pedido ATT standard, o que é um erro de implementação comum quando as equipas constroem um único binário para todos os públicos.

O Padrão de Engenharia que é Lançado

A arquitetura de aplicação híbrida que sobrevive tanto à revisão da App Store como a uma auditoria de privacidade da UE tem um pequeno número de elementos repetíveis. O banner CMP dentro da WKWebView é a fonte de verdade para o consentimento de publicidade. O pedido ATT é mostrado apenas depois de o CMP ter sido resolvido, apenas se o utilizador aceitou o consentimento de publicidade, e apenas com um pré-pedido personalizado que explica o que o rastreamento vai permitir. Uma ponte JavaScript expõe o estado de consentimento do CMP à camada nativa no início da aplicação e emite um evento a cada alteração de consentimento. Os SDKs da camada nativa dependem tanto do consentimento de publicidade do CMP como do estado de autorização ATT; qualquer um deles que recuse o pedido é suficiente para bloquear o SDK.

Pré-Pedidos e a Diretriz da Apple

A Apple permite — e na prática espera — um pré-pedido antes do pedido de sistema ATT que explica, com a voz do editor, por que a aplicação quer rastreamento e o que o utilizador recebe em troca. Um pré-pedido bem escrito pode aumentar substancialmente as taxas de opt-in. O que a Apple não permite é um pré-pedido que tente contornar o pedido do sistema, que represente erroneamente as consequências da recusa, ou que condicione a funcionalidade da aplicação à autorização de rastreamento. Os revisores rejeitam aplicações pelos três padrões e cada vez mais pelo uso do pré-pedido para induzir o opt-in com texto manipulador.

Lado do Servidor e SKAdNetwork como Alternativas

Quando o ATT é recusado ou o consentimento de publicidade é rejeitado na visualização web, o editor ainda pode recorrer ao SKAdNetwork para atribuição — a rede de preservação de privacidade da Apple que fornece dados de conversão sem expor identificadores individuais de utilizadores. O SKAdNetwork não está sujeito ao ATT e funciona independentemente da decisão de consentimento do utilizador, tornando-o o padrão correto para medição quando o caminho personalizado está fechado. As devoluções servidor a servidor da camada nativa para um serviço de identidade pertencente ao editor também podem preencher a lacuna de medição, desde que os dados sejam genuinamente de primeira parte e não sejam unidos com dados de outros operadores de forma que os remeta de volta para a definição de rastreamento da Apple.

Erros Comuns que Desencadeiam Rejeições ou Auditorias

As aplicações híbridas que são removidas ou multadas tendem a falhar nas mesmas situações. O banner CMP dentro da WKWebView é ativado antes de o pedido ATT ter sido resolvido, colocando cookies no dispositivo enquanto a permissão da Apple ainda está pendente — uma constatação que pode resultar na rejeição pela App Store. O pedido ATT é apresentado sem pré-pedido e no arranque a frio, produzindo taxas de opt-in baixas e uma experiência de utilizador confusa que aumenta a taxa de abandono. O SDK de análise da camada nativa lê o IDFA antes de o CMP ter emitido o seu primeiro evento de consentimento, colocando dados pessoais em circulação sem uma base jurídica clara. O estado de consentimento da visualização web e o estado de autorização da camada nativa são mantidos em armazenamentos separados sem sincronização, produzindo um utilizador que rejeitou a publicidade na visualização web mas cujo SDK de publicidade nativo ainda está a ser ativado. Cada um destes problemas é uma correção de um a dois dias de engenharia e uma passagem de teste de regressão — mas cada um é também o padrão exato com que um auditor ou revisor começa.

A Conclusão Final

O ATT e o consentimento de cookies não são camadas redundantes sobrepostas. O ATT é uma barreira de permissão limitada a uma API iOS específica, e o consentimento de cookies é uma base jurídica para processar dados em qualquer ambiente de classe de navegador, incluindo uma WKWebView. Uma aplicação híbrida precisa de ambos, ligados de forma que o utilizador veja uma decisão coerente em vez de dois pedidos contraditórios, e que a camada nativa e a visualização web respeitem a mesma resposta. Os editores que fazem isto corretamente lançam aplicações que passam na revisão, geram receita de forma fiável e nunca aparecem no resumo de execução de um regulador. Os editores que tratam o ATT como a resposta completa ou que deixam o consentimento da visualização web e a camada nativa divergirem passam 2026 a alternar entre reuniões de revisão da App Store e cartas de resposta a auditorias. Construa a ponte uma vez, trate o CMP como a fonte de verdade, e deixe que o ATT seja o bloqueio específico do iOS em cima de uma postura de privacidade que já é coerente ao nível web.