Como manter a sua política de privacidade em sincronia com o seu build

Escrever uma política de privacidade é um trabalho de uma vez só. Mantê-la verdadeira, não: a política descreve o build que você tinha quando a escreveu, e o build continua mudando. Um pull request adiciona relatório de falhas, uma biblioteca de assinaturas ou uma permissão de localização, o app é lançado, e a política, o formulário de Data safety e os detalhes de App Privacy ainda descrevem o app antigo.

As duas lojas tratam isso como problema seu, não delas. O Google Play diz que as suas respostas de Data safety precisam permanecer corretas e completas o tempo todo, e que os dados coletados por bibliotecas e SDKs de terceiros no seu app são seus para declarar. A Apple diz o mesmo sobre os detalhes de App Privacy, e acrescenta que você pode mudar as respostas no App Store Connect a qualquer momento, sem enviar uma atualização.

De onde a divergência realmente vem

Quase nunca de uma decisão de “coletar mais dados”. Ela vem do trabalho de engenharia comum:

• Uma dependência nova. Relatório de falhas, analytics, um SDK de paywall, uma biblioteca de mapas.
• Uma permissão nova. Localização para um recurso, a câmera para um scanner, rastreamento para anúncios.
• Um flavor ou target. Um build gratuito ganha um SDK de anúncios que o build pago não tem.
• Uma remoção. Também é divergência — a política agora declara a mais, o que é o erro mais seguro, mas continua sendo um erro.

Cada uma delas cai em um arquivo de build — build.gradle, AndroidManifest.xml, Podfile, Package.swift, Info.plist, pubspec.yaml, package.json. É isso que torna possível verificar.

A abordagem: um registro e uma verificação em cada pull request

1. Quando as suas páginas forem escritas, registre a partir do que elas foram escritas: os SDKs, os tipos de dados e as permissões presentes no build naquele momento.
2. Em cada pull request, leia os arquivos de build de novo e compare.
3. Quando algo for diferente, diga o quê, onde (arquivo e linha) e qual página ou formulário isso pode afetar.

Duas propriedades importam. A verificação precisa ler só arquivos de build — nunca código-fonte, nunca segredos —, para que seja segura de rodar em qualquer repositório. E ela precisa dizer “pode estar desatualizado”, não “violação”: uma biblioteca em um arquivo de build não prova que o app a usa, e só você sabe se ela muda o que o seu app coleta.

Como configurar com o AppFoyer

A verificação é gratuita em todos os planos. Ela lê só arquivos de build, não precisa de chave nem de segredo, não envia nada para lugar nenhum e nunca muda uma página.

Com o plugin do Claude Code

1. Diga “make this app store-ready” (deixe este app pronto para as lojas). Além de rascunhar as páginas, o plugin escreve appfoyer.json na raiz do seu repositório: o registro do que serviu de base para as páginas.
2. Diga “add the AppFoyer drift check” (adicione a verificação de divergência do AppFoyer). Ele mostra um workflow do GitHub e escreve .github/workflows/appfoyer.yml quando você disser que sim.
3. Faça commit dos dois arquivos. O plugin nunca faz commit nem push por você.

Sem o plugin

Adicione o workflow você mesmo:

name: AppFoyer drift check
on: pull_request
permissions:
  contents: read
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: appfoyer/check-action@v1

Abra um pull request. Sem nenhum appfoyer.json no repositório ainda, o job summary mostra o arquivo que seria escrito a partir do seu build. Compare-o com as suas páginas publicadas e faça commit dele.

Ou crie-o localmente — o mesmo scanner, publicado no npm:

npx @appfoyer/check init

Em outro sistema de CI

O pacote npm roda em qualquer lugar onde rode o Node 20 ou mais recente. Para o GitLab, por exemplo:

appfoyer-drift-check:
  image: node:22
  script:
    - npx -y @appfoyer/check --fail-on-drift

--format markdown gera o mesmo relatório que o job summary do GitHub mostra; --format json é para scripts.

Como é um resultado

Um pull request que adiciona o RevenueCat a um app cujas páginas foram escritas sem ele:

"Trail Notes": 2 changes
  + In-app purchases / subscriptions (data collected)  app/build.gradle.kts:28
      → Privacy policy may not declare "In-app purchases / subscriptions"
      → Google Play Data safety and Apple App Privacy answers may be outdated
      → Terms may not cover purchases and subscriptions
  + RevenueCat (SDK)  app/build.gradle.kts:28
      → Store forms: RevenueCat is not in the app's SDK list
      → Privacy policy may not name this SDK

Por padrão, o job relata e passa. Adicione fail-on-drift: "true" em with: para fazê-lo falhar até que o registro seja atualizado.

Quando ele relata uma mudança

1. Atualize o que a mudança afeta. Diga “make this app store-ready” de novo no mesmo branch: o plugin lê o build outra vez, atualiza os fatos do app, refaz o rascunho das páginas que a mudança afeta e reescreve o appfoyer.json. Ou edite você mesmo as páginas e a aba Store forms no painel.
2. Atualize o registro. O plugin já fez isso. Depois de uma edição no painel, rode npx @appfoyer/check update, ou copie o arquivo atualizado do job summary, onde ele fica abaixo dos resultados.
3. Faça commit dele no mesmo pull request. A próxima execução não mostra mudanças, e o histórico mostra a dependência e a mudança na divulgação chegando juntas.
4. Atualize os formulários das lojas nos consoles. Nem a verificação nem o AppFoyer conseguem acessar o Play Console ou o App Store Connect. As respostas em rascunho estão na aba Store forms do painel.
5. Publique os rascunhos atualizados na tela de revisão.

Vários apps em um repositório

O appfoyer.json guarda uma entrada por página de app na loja. Um product flavor com o seu próprio application id ganha a sua própria entrada, então um SDK de anúncios usado só pelo flavor gratuito é comparado com as páginas do flavor gratuito, e não com as do pago. O plugin escreve uma entrada para cada flavor que ele deixou pronto para as lojas. À mão, uma entrada recebe uma lista sourceSets — ["free"], ou, em um build com várias dimensões, cada flavor da combinação mais a própria combinação — e uma pasta root quando o app fica dentro de um monorepo.

O que ele não consegue ver

• Dependências de dependências, exceto no iOS, onde o Podfile.lock as lista. Um SDK trazido por outra biblioteca não aparece no seu arquivo de build, então também não aparece aqui.
• Configuração só em código. O app.config.js / app.config.ts no Expo é JavaScript e não é lido; o app.json e o package.json são.
• Se você usa o que declara. Uma dependência presente mas não usada ainda é relatada.
• O seu backend. Nada em um arquivo de build diz o que o seu servidor armazena nem por quanto tempo.

É um lembrete no momento em que divulgar uma mudança é mais barato, não um veredito de conformidade e não aconselhamento jurídico.

As fontes oficiais

• Provide information for Google Play’s Data safety section — Ajuda do Google Play Console: manter o formulário correto, e os dados de SDKs de terceiros
• App privacy details on the App Store — Apple: manter as respostas atualizadas, e atualizá-las sem uma atualização do app
• appfoyer/check-action e @appfoyer/check — a Action e o pacote npm, com o que eles leem