Cómo implementar PrivacyInfo.xcprivacy para apps y SDKs de iOS

¿Cómo implementar PrivacyInfo.xcprivacy para apps de iOS? Implementar PrivacyInfo.xcprivacy requiere añadir un manifiesto de privacidad válido a tu aplicación o destino de SDK, declarar códigos de razones aprobadas para cualquier API de razones requeridas que se utilice (como User Defaults o System Boot Time) y verificar que las dependencias de terceros cumplan con los requisitos de manifiesto de privacidad y firma aplicables a su forma de distribución.

Un manifiesto de privacidad (PrivacyInfo.xcprivacy) es un archivo de lista de propiedades estandarizado integrado en aplicaciones de iOS y SDKs de terceros que declara categorías de recogida de datos, configuraciones de dominios de rastreo y justificaciones aprobadas para acceder a las APIs de razones requeridas designadas por Apple. A partir del 1 de mayo de 2024, las apps enviadas a App Store Connect deben incluir razones aprobadas para las APIs de razones requeridas utilizadas por el código de la app, incluido el código de SDKs de terceros aplicables.

Comprender los requisitos del manifiesto de privacidad de Apple para SDKs de iOS

La arquitectura de los manifiestos de privacidad: manifiesto de la aplicación principal frente a manifiestos de SDKs incrustados

El marco de manifiestos de privacidad de Apple establece un modelo de transparencia modular en toda la cadena de suministro de software de iOS. En lugar de exigir a la aplicación host que audite y declare manualmente los detalles de implementación interna de cada biblioteca importada, Apple divide la gobernanza de la privacidad en capas diferenciadas:

• Manifiesto de la aplicación principal: cubre la recogida de datos de origen, los dominios de rastreo a nivel de app y las APIs de razones requeridas invocadas directamente por el código del destino de la aplicación principal.
• Manifiestos de SDKs incrustados: las declaraciones de APIs de razones requeridas deben pertenecer a la app o al código del SDK de terceros que utiliza dichas APIs. Para ejecutables y bibliotecas dinámicas, el paquete que contiene dicho ejecutable o biblioteca debe incluir el manifiesto de privacidad pertinente; un SDK de terceros no puede depender del manifiesto de la app host para informar sobre el uso de APIs de razones requeridas del SDK.
• Agregación automatizada de dependencias: cuando se archiva una aplicación en Xcode 15 o posterior, el sistema de compilación recorre el gráfico de dependencias, descubre todos los archivos PrivacyInfo.xcprivacy empaquetados y los agrupa en un único informe de privacidad unificado.

Las cuatro claves de configuración raíz

Cada archivo PrivacyInfo.xcprivacy se estructura como un diccionario de listas de propiedades XML que contiene hasta cuatro claves a nivel raíz:

• NSPrivacyTracking (Booleano): declara si la aplicación o el SDK utiliza los datos recopilados de la app para el rastreo según las definiciones de transparencia de rastreo de aplicaciones (ATT) de Apple.
• NSPrivacyTrackingDomains (Matriz de cadenas): enumera los dominios de internet a los que se conecta la app o el SDK y que realizan actividades de rastreo. Si un usuario no otorga la autorización ATT, iOS bloquea las conexiones de red a los dominios declarados en esta matriz. Si una app o un SDK no se conecta a dominios de rastreo, esta clave se puede omitir.
• NSPrivacyCollectedDataTypes (Matriz de diccionarios): informa sobre las categorías de datos definidas por Apple que la app o el SDK recopila sobre las personas que utilizan la aplicación, junto con si los datos están vinculados a la identidad del usuario, si se utilizan para el rastreo y los propósitos operativos para los que se recopilan.
• NSPrivacyAccessedAPITypes (Matriz de diccionarios): declara las APIs de razones requeridas designadas por Apple que invoca el binario, acompañadas de códigos de razones de cadena aprobados.

Aplicación de la ingesta en App Store Connect y diagnóstico de errores

App Store Connect aplica la obligatoriedad de los manifiestos de privacidad durante la ingesta de binarios:

• Falta de declaración de API (ITMS-91053): se activa cuando un binario compilado o una biblioteca vinculada llama a un símbolo de API de razones requeridas, pero falta la clave de categoría correspondiente en NSPrivacyAccessedAPITypes.
• Declaración de código de razón no válido: ocurre cuando un manifiesto declara una cadena de razón no aprobada, con formato incorrecto o obsoleta para una categoría de API específica.
• Falta de manifiesto de SDK de terceros requerido: se aplica en los escenarios de envío definidos por los requisitos actuales de SDKs de terceros de Apple para los SDKs enumerados, exigiendo tanto manifiestos de privacidad como firmas digitales válidas para las distribuciones de binarios.

Los desarrolladores que integren atribución de clientes y enlaces profundos pueden consultar la documentación de integración del SDK de iOS para ver las especificaciones técnicas relativas a las declaraciones de manifiestos.

Ver también: SDK de iOS ──> Arquitectura de atribución móvil

Categorías de APIs de razones requeridas y códigos de razones aprobadas

Las cinco categorías de APIs de razones requeridas

Según la Nota técnica TN3183 para desarrolladores de Apple, Apple define cinco categorías de API específicas que requieren códigos de justificación explícitos en NSPrivacyAccessedAPITypes. Los SDKs móviles y las aplicaciones de iOS interactúan habitualmente con cuatro categorías principales:

• NSPrivacyAccessedAPICategoryUserDefaults: acceso a la configuración local de la app mediante UserDefaults o NSUserDefaults.
• NSPrivacyAccessedAPICategorySystemBootTime: medición del tiempo transcurrido o marcas de tiempo mediante APIs de inicio del sistema como sysctl(KERN_BOOTTIME) o systemUptime.
• NSPrivacyAccessedAPICategoryDiskSpace: inspección de la capacidad del sistema de archivos mediante statfs, statvfs o volumeAvailableCapacityKey.
• NSPrivacyAccessedAPICategoryFileTimestamp: comprobación de las fechas de creación o modificación de archivos mediante stat, getattrlist o contentModificationDateKey.
• NSPrivacyAccessedAPICategoryActiveKeyboards: inspección de extensiones de teclado personalizadas activas (utilizado principalmente por utilidades de teclado especializadas).

Asignaciones de códigos de razones aprobadas seleccionadas para casos de uso comunes de SDKs

La siguiente tabla se centra en las categorías que se encuentran habitualmente en los SDKs móviles de propósito general; consulta la documentación actual de Apple para ver la lista completa de razones, incluidos los teclados activos. Para cumplir con las directrices de Apple, los desarrolladores deben seleccionar códigos de razón que coincidan estrictamente con su uso real de datos en tiempo de ejecución:

Construcción de un ejemplo de lista de propiedades PrivacyInfo.xcprivacy

Configuración de tipos de recopilación de datos

La matriz NSPrivacyCollectedDataTypes informa sobre las categorías de datos definidas por Apple que la app o el SDK recopila sobre las personas que utilizan la aplicación, junto con si los datos están vinculados a la identidad del usuario, si se utilizan para el rastreo y los propósitos operativos para los que se recopilan:

• NSPrivacyCollectedDataType: el identificador de cadena estándar de Apple (por ejemplo, NSPrivacyCollectedDataTypeDeviceID).
• NSPrivacyCollectedDataTypeLinked: un booleano que indica si los datos están vinculados a la identidad de un usuario individual.
• NSPrivacyCollectedDataTypeTracking: un booleano que indica si los datos se utilizan para el rastreo entre aplicaciones.
• NSPrivacyCollectedDataTypePurposes: una matriz de cadenas de propósitos estándar (por ejemplo, NSPrivacyCollectedDataTypePurposeAnalytics).

Declaración de dominios de rastreo

Si un SDK o aplicación realiza actividades de rastreo bajo las definiciones de ATT, todos los dominios de rastreo correspondientes deben declararse en NSPrivacyTrackingDomains. Si el usuario no otorga la autorización de rastreo, iOS bloquea las conexiones de red a los dominios declarados. Si la app o el SDK no realizan actividades de rastreo, NSPrivacyTracking debe configurarse como false y se puede omitir NSPrivacyTrackingDomains.

La configuración de la lista de propiedades a continuación ilustra un esquema de ejemplo de PrivacyInfo.xcprivacy. Incluye únicamente las categorías y razones que reflejen la implementación real de tu aplicación:

```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>NSPrivacyTracking</key>
    <false/>
    <key>NSPrivacyCollectedDataTypes</key>
    <array>
        <dict>
            <key>NSPrivacyCollectedDataType</key>
            <string>NSPrivacyCollectedDataTypeDeviceID</string>
            <key>NSPrivacyCollectedDataTypeLinked</key>
            <false/>
            <key>NSPrivacyCollectedDataTypeTracking</key>
            <false/>
            <key>NSPrivacyCollectedDataTypePurposes</key>
            <array>
                <string>NSPrivacyCollectedDataTypePurposeAnalytics</string>
                <string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
            </array>
        </dict>
    </array>
    <key>NSPrivacyAccessedAPITypes</key>
    <array>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>CA92.1</string>
            </array>
        </dict>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategorySystemBootTime</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>35F9.1</string>
            </array>
        </dict>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryDiskSpace</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>E174.1</string>
            </array>
        </dict>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>C617.1</string>
            </array>
        </dict>
    </array>
</dict>
</plist>

Solución de errores de firma de código en lotes de recursos de CocoaPods

La causa raíz: fallos de firma en lotes de recursos en Xcode 15 y 16

Al integrar dependencias mediante CocoaPods en Xcode 15 o 16, los desarrolladores se encuentran frecuentemente con interrupciones en la compilación:

Signing for "libOpoInstallSDK-OPPrivacy" requires a development team. Select a development team in the Signing & Capabilities editor.

Este fallo de compilación es un problema de integración entre Xcode y CocoaPods:

• Una biblioteca estática tradicional .a no puede contener directamente recursos como PrivacyInfo.xcprivacy. Apple recomienda empaquetar el código y los recursos de los SDKs estáticos juntos dentro de un framework estático.
• Algunas integraciones de CocoaPods generan en su lugar destinos de lotes de recursos independientes para distribuir recursos junto con bibliotecas estáticas.
• Ciertos destinos de lotes de recursos generados por CocoaPods pueden heredar configuraciones de firma que hacen que las compilaciones de Xcode se detengan solicitando un equipo de desarrollo. Este es un problema de integración del sistema de compilación más que un requisito del esquema de PrivacyInfo.xcprivacy.

Aplicación de soluciones alternativas específicas en el sistema de compilación dentro del Podfile

Para resolver este error en compilaciones automatizadas, los desarrolladores pueden utilizar un gancho post_install delimitado en el Podfile de su proyecto. Como se trata de una solución alternativa en el sistema de compilación para lotes de recursos no ejecutables, los equipos deben limitarla a los destinos de lotes afectados específicos o validar las dependencias afectadas antes de aplicar los cambios de forma global.

El script de Ruby que se muestra a continuación demuestra cómo recorrer los destinos de CocoaPods y deshabilitar la firma en los destinos de lotes de recursos designados:

post_install do |installer|
  # Especificar los destinos de lotes de recursos no ejecutables que experimentan errores de firma sin un equipo de desarrollo
  target_bundle_names = [
    'libOpoInstallSDK-OPPrivacy'
  ]

  installer.pods_project.targets.each do |target|
    if target.respond_to?(:product_type) &&
       target.product_type == "com.apple.product-type.bundle" &&
       target_bundle_names.include?(target.name)
      target.build_configurations.each do |config|
        # Eliminar el requisito de firma de código de los lotes de recursos no ejecutables designados
        config.build_settings['CODE_SIGNING_ALLOWED'] = 'NO'
        config.build_settings['CODE_SIGN_IDENTITY'] = ''
      end
    end
  end
end

Auditoría y generación del informe de privacidad agregado en Xcode

Generación del informe de privacidad unificado a través del organizador de archivos de Xcode (Archive Organizer)

Para verificar que todos los destinos de origen y las dependencias de terceros se han declarado correctamente antes de enviar un binario:

1. Abre tu proyecto en Xcode 15 o posterior.
2. Selecciona Product > Archive para crear un archivo de publicación.
3. En el organizador de Xcode (Organizer), haz clic derecho (o mantén pulsada la tecla Control y haz clic) en el archivo y selecciona Generate Privacy Report.
4. Guarda e inspecciona el informe en PDF generado para confirmar que todas las APIs de razones requeridas, las categorías de datos y los manifiestos de SDKs de terceros aparecen con precisión.

Análisis estático desde la línea de comandos: análisis heurísticos previos al envío

Los equipos de desarrollo pueden implementar auditorías heurísticas previas al envío dentro de las canalizaciones de integración continua (CI/CD) escaneando los binarios compilados en busca de símbolos restringidos utilizando nm y otool:

# Escanear el binario de la aplicación descomprimida en busca de símbolos candidatos de APIs de razones requeridas
nm -u /path/to/Payload/YourApp.app/YourApp | grep -E 'sysctl|statfs|statvfs|getattrlist|NSUserDefaults'

# Comprobar frameworks y paquetes incrustados en busca de manifiestos PrivacyInfo.xcprivacy
find /path/to/Payload/YourApp.app -name "PrivacyInfo.xcprivacy"

La presencia de un símbolo no establece por sí misma qué razón aprobada se aplica; revisa la ruta de llamada real y el caso de uso antes de modificar el manifiesto. Los equipos deben utilizar la función Generate Privacy Report de Xcode y las comprobaciones previas de App Store Connect para una verificación autorizada.

Matriz de diagnóstico: causas raíz de los rechazos de manifiestos de privacidad en la App Store

Resumen y marco de decisiones

El marco de manifiestos de privacidad de Apple impone la transparencia en toda la cadena de suministro de software de iOS. Garantizar envíos fluidos a la App Store requiere que los equipos de desarrollo auditen el código de origen para comprobar el uso de APIs de razones requeridas, verifiquen que las dependencias de SDKs de terceros cumplan con los requisitos de los manifiestos de privacidad aplicables a su uso de APIs y gestionen adecuadamente la firma de los lotes de recursos de CocoaPods.

Para declaraciones de manifiestos de privacidad específicas de productos, revisa la documentación de OpoInstall y compara el manifiesto incluido con la integración real de la aplicación y los requisitos actuales de Apple.

Materiales relacionados

• Conceptos: Manifiestos de privacidad, APIs de razones requeridas, firma de código en lotes de recursos, informes de privacidad, cumplimiento de la App Store

• Tecnologías: Xcode 15+, gestor de dependencias CocoaPods, Swift Package Manager, SDK de iOS de OpoInstall

• Estándares: Especificación del manifiesto de privacidad de Apple, sección 5.1.1 de las directrices de revisión de la App Store

• APIs y configuraciones: PrivacyInfo.xcprivacy, NSPrivacyAccessedAPITypes, gancho post_install del Podfile

Documentación oficial

• Documentación para desarrolladores de Apple sobre la descripción del uso de APIs de razones requeridas

• Documentación para desarrolladores de Apple sobre archivos de manifiesto de privacidad

• Documentación para desarrolladores de Apple sobre los próximos requisitos para SDKs de terceros

• Sección 5.1.1 de las directrices de revisión de la App Store de Apple