Apple ha anunciado cambios en App Tracking Transparency (ATT) para la Unión Europea a partir de iOS 27.2 y iPadOS 27.2. La actualización introduce una presentación alternativa del permiso, más espacio para explicar el uso de los datos y la posibilidad de solicitarlo de nuevo después de un año. Para quienes mantenemos aplicaciones con publicidad o SDKs de atribución, afecta tanto a la interfaz como a la lógica que decide cuándo pedir autorización.
Según el anuncio de Apple, el cambio responde a acuerdos con determinadas autoridades europeas de competencia. En Alemania, Francia, Italia, Polonia y Rumanía solo estará disponible la nueva presentación. En el resto de la UE, incluida España, los desarrolladores podrán optar por ella. Los requisitos que determinan cuándo hay que pedir permiso permanecen vigentes: una interfaz distinta no autoriza usos adicionales de los datos.
Conviene recordar qué cubre ATT. Apple considera seguimiento vincular datos de tu aplicación con información procedente de otras empresas para publicidad dirigida o medición publicitaria, así como compartirlos con intermediarios de datos. Esto puede ocurrir a través de un SDK aunque tú no utilices expresamente sus funciones publicitarias. Cambiar el IDFA por un correo con hash tampoco evita la necesidad de autorización. La guía de privacidad de Apple explica estos casos.
La nueva API permite solicitar una hoja a página completa mediante usingExpandedInterface y añadir una acción opcional de información adicional. La selección regional corresponde al sistema y considera tanto la ubicación del dispositivo como el país o región de la cuenta de Apple. Fuera de la UE, los nuevos parámetros se ignoran y aparece el aviso tradicional. Por tanto, comprobar Locale.current no sustituye los criterios del sistema.
En una app de rutas ciclistas financiada con publicidad, podríamos encapsular la solicitud así. El ejemplo utiliza la variante asíncrona documentada por Apple y requiere un SDK que incluya las APIs de iOS 27.2:
import AppTrackingTransparency
import UIKit
@MainActor
func requestCyclingAppTrackingPermission() async
-> ATTrackingManager.AuthorizationStatus {
guard UIApplication.shared.applicationState == .active else {
return ATTrackingManager.trackingAuthorizationStatus
}
if #available(iOS 27.2, *) {
return await ATTrackingManager.requestTrackingAuthorization(
usingExpandedInterface: true,
additionalInformationAction: nil
)
} else {
return await ATTrackingManager.requestTrackingAuthorization()
}
}
Aquí nil omite el botón de información adicional. La función solo obtiene el estado: el código que la llama debe aplicar el resultado a los servicios que realizan seguimiento. Solo .authorized permite habilitarlo; no conviene iniciar un SDK con seguimiento activo y corregir su configuración después. Tampoco hace falta ejecutar esta función en cada aparición de una vista: el momento de solicitar permiso debe formar parte de un flujo deliberado de la aplicación.
La configuración conserva una pieza imprescindible: NSUserTrackingUsageDescription. Esta clave explica para qué se utilizarán los datos y sigue siendo obligatoria. Apple advierte de que intentar utilizar el framework sin incluirla provoca un fallo de la app. El texto debe ser breve y concreto; no necesita repetir el nombre de la aplicación, porque el sistema ya lo muestra.
La novedad es NSUserTrackingMarkdownUsageDescription, una clave opcional que admite negrita, cursiva, listas con viñetas y saltos de párrafo. No admite subrayado. Si falta, el sistema utiliza la descripción tradicional. Para la app del ejemplo, su valor podría ser:
Usaremos datos sobre tu actividad para:
* Mostrarte **anuncios personalizados** combinando información
de esta app con datos de apps y sitios web de otras empresas.
* Medir la eficacia de esos anuncios.
Este texto enriquecido tiene disponibilidad regional: en los cinco países indicados se utiliza cuando está presente; en el resto de la UE, la documentación de la clave lo vincula a solicitar la interfaz ampliada. Fuera de la UE se utiliza la descripción original. Mantener ambos textos revisados y localizados evita que una explicación se quede desactualizada. El ejemplo debe adaptarse a los usos reales de cada app y de sus proveedores.
El botón opcional de información adicional tiene una consecuencia fácil de pasar por alto: al pulsarlo, la hoja se descarta sin registrar una decisión y se ejecuta el bloque proporcionado. La finalización recibe .notDetermined. Después de mostrar la explicación propia, la app puede volver a solicitar permiso. Ese resultado no equivale a un rechazo y merece un tratamiento distinto en la navegación.
Esa pantalla adicional también puede ofrecer controles más detallados, pero sus respuestas deben ser coherentes con ATT. Apple indica que no se debe redirigir otra vez al permiso si el usuario ha rechazado todas las opciones relevantes en esos controles. Tampoco permite condicionar funciones a aceptar el seguimiento ni incentivar la aceptación. Añadir espacio para explicar el tratamiento de datos no convierte el consentimiento en un requisito para usar la app.
Otro cambio relevante es la nueva solicitud anual. La documentación de autorización explica que, en la UE, el sistema registra la fecha de la respuesta y permite volver a preguntar cuando transcurre un año, tanto si el usuario aceptó como si rechazó. Si ha desactivado las solicitudes de seguimiento en Ajustes, no se puede volver a mostrar el permiso. Poder preguntar de nuevo no significa que la autorización caduque automáticamente al cumplir un año.
Esto invita a revisar patrones como guard status == .notDetermined else { return }: si se aplican siempre, impiden que la app llegue a realizar la nueva solicitud anual. No se trata de eliminarlos indiscriminadamente, sino de distinguir la primera solicitud de una nueva petición planificada. El sistema aplica el límite temporal. Además, la documentación señala que no presenta el diálogo con la app inactiva, desde una extensión o cuando ya existe otra solicitud pendiente.
Para preparar la actualización, conviene probar la instalación inicial, una decisión existente, las restricciones del dispositivo y el regreso desde la pantalla de información adicional. También hay que revisar qué hace cada SDK antes de obtener permiso y al volver desde Ajustes. La parte más importante de esta migración es que la explicación, el estado de ATT y el comportamiento efectivo de la app coincidan, independientemente del formato del diálogo que presente el sistema.