iOS App Tracking Transparency (ATT) e consentimento de cookies para aplicacións híbridas en 2026
As aplicacións móbiles híbridas — a arquitectura na que un fino envoltorio nativo contén unha vista web que renderiza a maior parte da interface de usuario — sempre viviron á vez en dous mundos de privacidade. O envoltorio nativo está rexido polo marco App Tracking Transparency (ATT) de Apple en iOS e pola folla de ruta Privacy Sandbox de Google en Android. A vista web interior está rexida polos mesmos regulamentos de GDPR, ePrivacy, CCPA e CPRA que se aplican a calquera navegador. Durante cinco anos, os editores tentaron parchar a costura con solucións ad hoc, e durante cinco anos, os revisores de App Store e os reguladores da UE rexeitaron o remendo en proporcións aproximadamente iguais. En 2026, a cuestión de como ATT e o consentimento de cookies encaixan xuntos dentro dunha aplicación híbrida xa non é fontanería opcional: é a diferenza entre unha aplicación que se lanza, monetiza e supera unha auditoría de privacidade, e unha que se retira da tenda ou recibe unha multa que obriga a reconstruíla. Esta guía percorre o que ATT controla realmente, o que deixa deliberadamente ao consentimento web, como deseñar o fluxo de permiso e consentimento para que os dous sistemas sexan coherentes en lugar de contraditorios, e os patróns de enxeñería que sobreviven tanto ao proceso de revisión de Apple coma á auditoría dun regulador.
O que App Tracking Transparency Rexe Realmente
ATT é unha porta de permiso que Apple aplica en iOS e iPadOS. Cando unha aplicación quere acceder ao Identifier for Advertisers (IDFA) do dispositivo ou realizar un seguimento que vincula ao usuario entre aplicacións e sitios web pertencentes a outros operadores, debe chamar a requestTrackingAuthorization e mostrar un indicador do sistema que lle pida ao usuario que permita ou deniegue o seguimento. A resposta do usuario é binaria, persistente ata que a cambie en Configuración, e visible para a aplicación a través da API trackingAuthorizationStatus.
A Definición de Seguimento de Apple
A guía para desenvolvedores de Apple define o seguimento de forma específica e estreita: vincular datos de usuario ou dispositivo recollidos da túa aplicación con datos de usuario ou dispositivo recollidos de aplicacións, sitios web ou propiedades offline de outras empresas para publicidade dirixida ou medición, ou compartir datos de usuario ou dispositivo con intermediarios de datos. A definición exclúe deliberadamente o uso de primeira parte dos datos dentro da aplicación, a análise agregada anónima e o procesamento para a prevención de fraude ou o cumprimento legal — estas actividades non requiren un indicador ATT independentemente de se o usuario o concedeu.
O que ATT Non Fai
ATT non é un sistema de xestión do consentimento no sentido do GDPR. Non recolle preferencias de finalidade granulares, non rexistra un recibo de consentimento con versión de política, non propaga sinais a vendedores web dentro dun WKWebView e non satisfai o requisito de base xurídica para almacenar ou ler cookies no dispositivo dun usuario. Un editor que trata o indicador ATT como toda a súa postura de cumprimento para unha aplicación híbrida está a unha carta de regulador dunha multa, xa que a carga de cookies dentro da vista web é un evento separado baixo ePrivacy e necesita a súa propia capa de consentimento.
Como se Aplican GDPR e ePrivacy Dentro dun WKWebView
A vista web dentro dunha aplicación híbrida non está máxicamente exenta das regras que se aplican a un navegador de escritorio. No momento en que o WKWebView le ou escribe unha cookie que non é estritamente necesaria, actívase ePrivacy. No momento en que o WKWebView envía unha solicitude de análise ou publicidade que leva datos persoais, actívase GDPR. O contedor de Apple non cambia a análise — o que cambia é a superficie de implementación, xa que o banner de consentimento debe renderizarse dentro da vista web e o estado do consentimento debe ser visible para o código nativo que tamén pode estar a ler os mesmos datos.
O Banner Dentro da Vista Web
O patrón estándar é renderizar un banner CMP dentro do WKWebView do mesmo xeito que faría nun sitio web. O banner establece cookies na tenda de cookies da vista web, dispara un evento de actualización do consentimento no contexto JavaScript da páxina e actualiza a máquina de estado Google Consent Mode v2 que len as etiquetas de análise e publicidade da páxina. A implementación non é diferente da dun CMP web normal — o que é diferente é que a tenda de cookies está delimitada ao WKWebView e non é visible para outras aplicacións nin para Safari, o que é útil para o illamento pero non é útil se o editor tamén xestiona un sitio web onde o usuario xa deuse por consentido.
Compartir o Consentimento Entre a Vista Web e o Envoltorio Nativo
O problema máis difícil é a ponte entre o WKWebView e o envoltorio nativo. O envoltorio nativo pode ter o seu propio SDK de análise que le o IDFA despois de que o usuario concedese ATT, mentres que a vista web ten o seu propio banner de consentimento que o usuario pode ou non ter aceptado. Se o usuario concede ATT pero rexeita o consentimento publicitario na vista web, o SDK nativo aínda pode ler o IDFA pero as etiquetas da vista web non deben. Se o usuario denega ATT pero acepta o consentimento publicitario da vista web, o SDK nativo está bloqueado pero as etiquetas da vista web aínda deben dispararse — aínda que o identificador baseado en IDFA do SDK nativo obviamente non pode pasar pola ponte. O patrón máis limpo é unha única fonte de verdade — o CMP — exposta a través dunha ponte JavaScript que o envoltorio nativo le ao iniciar a aplicación e en cada cambio de consentimento, cun indicador ATT paralelo que delega na decisión publicitaria do CMP en lugar de preguntar de novo.
A Capa de CPRA e os Estados dos EUA
Para os editores dos EUA, o panorama ten unha terceira capa. CPRA, xunto co cúmulo de leis estatais que seguiron a Virginia, Colorado, Connecticut e Utah, trata ao IDFA do mesmo xeito que tratan as cookies web — ambas son información persoal cuxa venda ou intercambio activa un dereito de exclusión. A cabeceira Global Privacy Control que envían os navegadores web é o sinal orientado ao consumidor, e o Multi-State Privacy Agreement (MSPA) da IAB coa súa cadea US Privacy asociada é o sinal orientado ao editor. Unha aplicación híbrida que se lanza nos EUA necesita expor un enlace "Non vender nin compartir a miña información persoal" dentro da propia aplicación, enrutar a exclusión resultante tanto ao CMP da vista web coma ao SDK de medición do envoltorio nativo, e respectar calquera cabeceira GPC entrante que chegue á vista web desde un enlace profundo.
Nenos e COPPA Dentro das Aplicacións Híbridas
Se a aplicación está valorada para nenos ou existe calquera expectativa razoable de usuarios menores, a COPPA nos EUA e as disposicións GDPR-K na UE engaden restricións adicionais encima do ATT e o consentimento estándar. Non se debe solicitar o IDFA en absoluto para as contas infantís, o consentimento publicitario da vista web debe ter como valor predeterminado a denegación, e calquera SDK de terceiros no envoltorio nativo debe estar confirmado como conforme a COPPA antes de lanzarse. A revisión de App Store rexeita as aplicacións valoradas para nenos que mostran o indicador ATT estándar, o que é un erro de implementación común cando os equipos crean un único binario para todas as audiencias.
O Patrón de Enxeñería que se Lanza
A arquitectura de aplicación híbrida que sobrevive tanto á revisión de App Store coma a unha auditoría de privacidade da UE ten un pequeno número de elementos repetibles. O banner CMP dentro do WKWebView é a fonte de verdade para o consentimento publicitario. O indicador ATT só se mostra despois de que o CMP resolva, só se o usuario aceptou o consentimento publicitario, e só cun pre-indicador personalizado que explica o que o seguimento habilitará. Unha ponte JavaScript expón o estado de consentimento do CMP ao envoltorio nativo ao iniciar a aplicación e emite un evento en cada cambio de consentimento. Os SDK do envoltorio nativo están condicionados tanto ao consentimento publicitario do CMP coma ao estado de autorización ATT; calquera dos dous denegando a solicitude é suficiente para bloquear o SDK.
Pre-Indicadores e a Directriz de Apple
Apple permite — e na práctica espera — un pre-indicador antes do indicador de sistema ATT que explica en voz do editor por que a aplicación quere seguimento e o que o usuario obtén a cambio. Un pre-indicador ben redactado pode elevar substancialmente as taxas de opt-in. O que Apple non permite é un pre-indicador que intente eludir o indicador do sistema, que terxiversa as consecuencias da denegación, ou que condiciona a funcionalidade da aplicación á autorización de seguimento. Os revisores rexeitan as aplicacións polos tres patróns e cada vez máis por usar o pre-indicador para incitar ao opt-in con texto manipulador.
O Lado do Servidor e SKAdNetwork como Alternativas
Cando se denega ATT ou se rexeita o consentimento publicitario na vista web, o editor aínda pode recorrer a SKAdNetwork para a atribución — a rede de conservación da privacidade de Apple que entrega datos de conversión sen expor identificadores de usuario individuais. SKAdNetwork non está suxeito ao ATT e funciona independentemente da decisión de consentimento do usuario, o que o converte na opción predeterminada correcta para a medición cando o camiño personalizado está pechado. Os postbacks de servidor a servidor desde o envoltorio nativo a un servizo de identidade de propiedade do editor tamén poden cubrir a lagoa de medición, sempre que os datos sexan genuinamente de primeira parte e non se combinen cos datos doutros operadores de xeito que os devolva á definición de seguimento de Apple.
Erros Comúns que Provocan Rexeitamentos ou Auditorías
As aplicacións híbridas que se retiran ou se multan tenden a fallar dos mesmos xeitos. O banner CMP dentro do WKWebView dispárase antes de que se resolva o indicador ATT, colocando cookies no dispositivo mentres o permiso de Apple aínda está pendente — un achado que pode resultar nun rexeitamento de App Store. O indicador ATT móstrase sen pre-indicador e no arranque en frío, producindo baixas taxas de opt-in e unha experiencia de usuario confusa que aumenta a abandono. O SDK de análise do envoltorio nativo le o IDFA antes de que o CMP disparase o seu primeiro evento de consentimento, enviando datos persoais sen unha base xurídica clara. O estado de consentimento da vista web e o estado de autorización do envoltorio nativo mantéñense en almacéns separados sen sincronización, producindo un usuario que rexeitou a publicidade na vista web pero cuxo SDK de anuncios nativo aínda se dispara. Cada un destes é un arranxo dun a dous días de enxeñería e un pase de proba de regresión — pero cada un é tamén o patrón exacto co que abre un auditor ou un revisor.
A Conclusión
ATT e o consentimento de cookies non son capas redundantes. ATT é unha porta de permiso delimitada a unha API de iOS específica, e o consentimento de cookies é unha base xurídica para o procesamento de datos dentro de calquera ambiente de clase de navegador, incluíndo un WKWebView. Unha aplicación híbrida necesita ambas, conectadas xuntas para que o usuario vexa unha decisión coherente en lugar de dúas indicacións contradictorias, e para que o envoltorio nativo e a vista web honren a mesma resposta. Os editores que conseguen isto lanzan aplicacións que pasan a revisión, monetizan de forma fiable e nunca aparecen no resumo de aplicación dun regulador. Os editores que tratan ATT como a resposta completa ou que permiten que o consentimento da vista web e o envoltorio nativo se distancien pasan o 2026 alternando entre reunións de revisión de App Store e cartas de resposta de auditoría. Construíde a ponte unha vez, tratade o CMP como a fonte de verdade, e deixade que ATT sexa o bloqueo específico de iOS encima dunha postura de privacidade que xa é coherente na capa web.