Como Implementar o PrivacyInfo.xcprivacy para Aplicativos e SDKs iOS

Como implementar o PrivacyInfo.xcprivacy para aplicativos iOS? A implementação do PrivacyInfo.xcprivacy exige a adição de um manifesto de privacidade válido ao alvo do seu aplicativo ou SDK, a declaração de códigos de motivo aprovados para quaisquer APIs de Motivo Obrigatório utilizadas (como User Defaults ou System Boot Time) e a verificação de que dependências de terceiros atendem aos requisitos de manifesto de privacidade e assinatura aplicáveis à sua forma de distribuição.

Um manifesto de privacidade (PrivacyInfo.xcprivacy) é um arquivo de lista de propriedades padronizado empacotado em aplicativos iOS e SDKs de terceiros que declara categorias de coleta de dados, configurações de domínios de rastreamento e justificativas aprovadas para acessar APIs de Motivo Obrigatório designadas pela Apple. A partir de 1 de maio de 2024, os aplicativos enviados para a App Store Connect devem incluir motivos aprovados para as APIs de Motivo Obrigatório usadas pelo código do aplicativo, incluindo o código de SDKs de terceiros aplicáveis.

Compreendendo os Requisitos do Manifesto de Privacidade da Apple para SDKs iOS

A Arquitetura dos Manifestos de Privacidade: Manifesto do Aplicativo Principal vs. Manifestos de SDKs Incorporados

A estrutura de manifesto de privacidade da Apple estabelece um modelo de transparência modular em toda a cadeia de suprimentos de software iOS. Em vez de exigir que o aplicativo host audite e declare manualmente os detalhes de implementação interna de cada biblioteca importada, a Apple divide a governança de privacidade em camadas distintas:

• Manifesto do Aplicativo Principal: Abrange a coleta de dados primários, domínios de rastreamento em nível de aplicativo e APIs de Motivo Obrigatório invocadas diretamente pelo código do alvo do aplicativo principal.
• Manifestos de SDKs Incorporados: As declarações de APIs de Motivo Obrigatório devem pertencer ao aplicativo ou ao código do SDK de terceiros que utiliza essas APIs. Para executáveis e bibliotecas dinâmicas, o pacote contendo esse executável ou biblioteca deve incluir o manifesto de privacidade relevante; um SDK de terceiros não pode depender do manifesto do aplicativo host para relatar o uso da API de Motivo Obrigatório do SDK.
• Agregação Automatizada de Dependências: Quando um aplicativo é arquivado no Xcode 15 ou posterior, o sistema de build percorre o gráfico de dependências, descobre todos os arquivos PrivacyInfo.xcprivacy empacotados e os agrega em um Relatório de Privacidade unificado.

As Quatro Chaves de Configuração Raiz

Cada arquivo PrivacyInfo.xcprivacy é estruturado como um dicionário de lista de propriedades XML contendo até quatro chaves de nível raiz:

• NSPrivacyTracking (Booleano): Declara se o aplicativo ou SDK usa dados coletados do aplicativo para rastreamento sob as definições de Transparência de Rastreamento de Aplicativos (ATT) da Apple.
• NSPrivacyTrackingDomains (Matriz de Strings): Lista os domínios de internet conectados pelo aplicativo ou SDK que realizam rastreamento. Se um usuário não conceder autorização ATT, o iOS bloqueará conexões de rede para os domínios declarados nesta matriz. Se um aplicativo ou SDK não se conectar a domínios de rastreamento, esta chave poderá ser omitida.
• NSPrivacyCollectedDataTypes (Matriz de Dicionários): Relata as categorias de dados definidas pela Apple que o aplicativo ou SDK coleta sobre as pessoas que utilizam o aplicativo, juntamente com informações sobre se os dados estão vinculados à identidade do usuário, se são usados para rastreamento e as finalidades operacionais para as quais são coletados.
• NSPrivacyAccessedAPITypes (Matriz de Dicionários): Declara as APIs de Motivo Obrigatório designadas pela Apple invocadas pelo binário, acompanhadas de códigos de motivo de string aprovados.

Imposição de Ingestão na App Store Connect e Diagnóstico de Erros

A App Store Connect impõe manifestos de privacidade durante a ingestão do binário:

• Declaração de API Ausente (ITMS-91053): Acionado quando um binário compilado ou biblioteca vinculada chama um símbolo de API de Motivo Obrigatório, mas a chave de categoria correspondente está ausente em NSPrivacyAccessedAPITypes.
• Declaração de Código de Motivo Inválido: Ocorre quando um manifesto declara uma string de motivo não aprovada, malformada ou obsoleta para uma categoria de API específica.
• Manifesto de SDK de Terceiros Obrigatório Ausente: Aplicado nos cenários de envio definidos pelos requisitos atuais de SDK de terceiros da Apple para os SDKs listados, exigindo tanto manifestos de privacidade quanto assinaturas digitais válidas para distribuições binárias.

Os desenvolvedores que integram atribuição de clientes e links profundos podem consultar a documentação de integração do SDK iOS para obter especificações técnicas referentes às declarações de manifesto.

Veja Também: SDK iOS ──> Arquitetura de Atribuição Móvel

Categorias de API de Motivo Obrigatório e Códigos de Motivo Aprovados

As Cinco Categorias de API de Motivo Obrigatório

De acordo com a Nota Técnica TN3183 do Desenvolvedor Apple, a Apple define cinco categorias de API específicas que exigem códigos de justificativa explícitos em NSPrivacyAccessedAPITypes. Os SDKs móveis e aplicativos iOS interagem comumente com quatro categorias principais:

• NSPrivacyAccessedAPICategoryUserDefaults: Acesso a configurações locais do aplicativo via UserDefaults ou NSUserDefaults.
• NSPrivacyAccessedAPICategorySystemBootTime: Medição de tempo decorrido ou carimbos de data/hora usando APIs de inicialização do sistema como sysctl(KERN_BOOTTIME) ou systemUptime.
• NSPrivacyAccessedAPICategoryDiskSpace: Inspeção da capacidade do sistema de arquivos via statfs, statvfs ou volumeAvailableCapacityKey.
• NSPrivacyAccessedAPICategoryFileTimestamp: Verificação de datas de criação ou modificação de arquivos via stat, getattrlist ou contentModificationDateKey.
• NSPrivacyAccessedAPICategoryActiveKeyboards: Inspeção de extensões de teclado personalizadas ativas (usado principalmente por utilitários de teclado especializados).

Mapeamentos Selecionados de Códigos de Motivo Aprovados para Casos de Uso Comuns de SDK

A tabela abaixo foca em categorias comumente encontradas em SDKs móveis de uso geral; consulte a documentação atual da Apple para obter a lista completa de motivos, incluindo Teclados Ativos. Para cumprir as diretrizes da Apple, os desenvolvedores devem selecionar códigos de motivo que correspondam estritamente ao uso real de dados em tempo de execução:

Construindo um Exemplo de Lista de Propriedades PrivacyInfo.xcprivacy

Configurando Tipos de Coleta de Dados

A matriz NSPrivacyCollectedDataTypes relata as categorias de dados definidas pela Apple que o aplicativo ou SDK coleta sobre as pessoas que usam o aplicativo, juntamente com se os dados estão vinculados à identidade do usuário, se são usados para rastreamento e as finalidades operacionais para as quais são coletados:

• NSPrivacyCollectedDataType: O identificador de string padrão da Apple (por exemplo, NSPrivacyCollectedDataTypeDeviceID).
• NSPrivacyCollectedDataTypeLinked: Um booleano indicando se os dados estão vinculados à identidade de um usuário individual.
• NSPrivacyCollectedDataTypeTracking: Um booleano indicando se os dados são usados para rastreamento entre aplicativos.
• NSPrivacyCollectedDataTypePurposes: Uma matriz de strings de finalidade padrão (por exemplo, NSPrivacyCollectedDataTypePurposeAnalytics).

Declarando Domínios de Rastreamento

Se um SDK ou aplicativo realizar rastreamento sob as definições de ATT, todos os domínios de rastreamento correspondentes devem ser declarados em NSPrivacyTrackingDomains. Se a autorização de rastreamento não for concedida pelo usuário, o iOS bloqueará conexões de rede para os domínios declarados. Se o aplicativo ou SDK não realizar rastreamento, NSPrivacyTracking deve ser definido como false e NSPrivacyTrackingDomains pode ser omitido.

A configuração da lista de propriedades abaixo ilustra um exemplo de esquema PrivacyInfo.xcprivacy. Inclua apenas as categorias e os motivos que refletem a implementação real do seu aplicativo:

```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>

Resolvendo Erros de Assinatura de Código de Pacote de Recursos do CocoaPods

A Causa Raiz: Falhas de Assinatura de Pacote de Recursos no Xcode 15 e 16

Ao integrar dependências via CocoaPods no Xcode 15 ou 16, os desenvolvedores encontram frequentemente interrupções na compilação:

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

Essa falha de build é um problema de integração entre o Xcode e o CocoaPods:

• Uma biblioteca estática tradicional .a não pode conter diretamente recursos como o PrivacyInfo.xcprivacy. A Apple recomenda empacotar o código do SDK estático e os recursos juntos dentro de um framework estático.
• Algumas integrações do CocoaPods geram, em vez disso, alvos de pacotes de recursos separados para distribuir recursos juntamente com bibliotecas estáticas.
• Certos alvos de pacotes de recursos gerados pelo CocoaPods podem herdar configurações de assinatura que fazem com que os builds do Xcode parem solicitando uma equipe de desenvolvimento. Este é um problema de integração do sistema de build e não um requisito de esquema do PrivacyInfo.xcprivacy.

Aplicando Soluções Temporárias Direcionadas no Sistema de Build do Podfile

Para resolver esse erro em builds automatizados, os desenvolvedores podem usar um gancho post_install com escopo definido em seu Podfile do projeto. Como essa é uma solução temporária do sistema de build para pacotes de recursos não executáveis, as equipes devem limitá-la a alvos de pacotes afetados específicos ou validar as dependências afetadas antes de aplicar as alterações globalmente.

O script Ruby abaixo demonstra como iterar pelos alvos do CocoaPods e desativar a assinatura em alvos de pacotes de recursos designados:

post_install do |installer|
  # Specify non-executable resource bundle targets that encounter signing errors without a development team
  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|
        # Strip code signing requirement from designated non-executable resource bundles
        config.build_settings['CODE_SIGNING_ALLOWED'] = 'NO'
        config.build_settings['CODE_SIGN_IDENTITY'] = ''
      end
    end
  end
end

Auditando e Gerando o Relatório de Privacidade Agregado no Xcode

Gerando o Relatório de Privacidade Unificado via Xcode Archive Organizer

Para verificar se todos os alvos primários e dependências de terceiros estão declarados corretamente antes de enviar um binário:

1. Abra seu projeto no Xcode 15 ou posterior.
2. Selecione Product > Archive para criar um arquivo de lançamento (archive).
3. No Xcode Organizer, clique com o botão direito (ou Control-clique) no arquivo e selecione Generate Privacy Report.
4. Salve e inspecione o relatório PDF gerado para confirmar se todas as APIs de Motivo Obrigatório, categorias de dados e manifestos de SDKs de terceiros aparecem com precisão.

Análise Estática via Linha de Comando: Varreduras Heurísticas Pré-Envio

As equipes de desenvolvimento podem implementar auditorias heurísticas pré-envio dentro de pipelines de integração contínua (CI/CD) escaneando binários compilados em busca de símbolos restritos usando nm e otool:

# Scan unpacked application binary for candidate Required Reason API symbols
nm -u /path/to/Payload/YourApp.app/YourApp | grep -E 'sysctl|statfs|statvfs|getattrlist|NSUserDefaults'

# Check embedded frameworks and bundles for PrivacyInfo.xcprivacy manifests
find /path/to/Payload/YourApp.app -name "PrivacyInfo.xcprivacy"

A presença de símbolos por si só não estabelece qual motivo aprovado se aplica; revise o caminho real da chamada e o caso de uso antes de modificar o manifesto. As equipes devem usar a opção Generate Privacy Report do Xcode e as verificações preliminares da App Store Connect para verificação autoritativa.

Matriz de Diagnóstico: Causas Raiz de Rejeições de Manifesto de Privacidade na App Store

Resumo e Estrutura de Decisão

A estrutura de Manifesto de Privacidade da Apple impõe transparência em toda a cadeia de suprimentos de software iOS. Garantir envios para a App Store sem atritos exige que as equipes de desenvolvimento auditem o código proprietário quanto ao uso de APIs de Motivo Obrigatório, verifiquem se as dependências de SDKs de terceiros atendem aos requisitos de manifesto de privacidade aplicáveis ao uso de suas APIs e gerenciem adequadamente a assinatura de pacotes de recursos do CocoaPods.

Para declarações de manifesto de privacidade específicas do produto, analise a documentação do OpoInstall e compare o manifesto enviado com a integração real do aplicativo e os requisitos atuais da Apple.

Materiais Relacionados

• Conceitos: Manifestos de Privacidade, APIs de Motivo Obrigatório, Assinatura de Código de Pacotes de Recursos, Relatórios de Privacidade, Conformidade com a App Store

• Tecnologias: Xcode 15+, Gerenciador de Dependências CocoaPods, Swift Package Manager, SDK iOS do OpoInstall

• Padrões: Especificação de Manifesto de Privacidade da Apple, Seção 5.1.1 das Diretrizes de Revisão da App Store

• APIs e Configurações: PrivacyInfo.xcprivacy, NSPrivacyAccessedAPITypes, gancho post_install do Podfile

Documentação Oficial

• Documentação do Desenvolvedor Apple sobre como Descrever o Uso da API de Motivo Obrigatório

• Documentação do Desenvolvedor Apple sobre Arquivos de Manifesto de Privacidade

• Documentação do Desenvolvedor Apple sobre os Próximos Requisitos de SDKs de Terceiros

• Seção 5.1.1 das Diretrizes de Revisão da App Store da Apple