Mantenere l'informativa sulla privacy allineata alla tua build

Scrivere un’informativa sulla privacy è un lavoro da fare una volta. Mantenerla vera no: l’informativa descrive la build che avevi quando l’hai scritta, e la build continua a cambiare. Una pull request aggiunge il crash reporting, una libreria per gli abbonamenti o un permesso di localizzazione, l’app viene rilasciata, e l’informativa, il modulo Data safety e i dettagli App Privacy descrivono ancora la vecchia app.

Entrambi gli store considerano questo un problema tuo, non loro. Google Play dice che le tue risposte Data safety devono restare accurate e complete in ogni momento, e che i dati raccolti dalle librerie e dagli SDK di terze parti nella tua app li devi dichiarare tu. Apple dice lo stesso dei dettagli App Privacy, e aggiunge che puoi modificare le risposte in App Store Connect in qualsiasi momento senza inviare un aggiornamento.

Da dove nasce davvero la divergenza

Quasi mai da una decisione di «raccogliere più dati». Nasce dal normale lavoro di sviluppo:

• Una nuova dipendenza. Crash reporting, analytics, un SDK per paywall, una libreria di mappe.
• Un nuovo permesso. La posizione per una funzione, la fotocamera per uno scanner, il tracciamento per gli annunci.
• Un flavor o un target. Una build gratuita acquisisce un SDK pubblicitario che la build a pagamento non ha.
• Una rimozione. Anche questa è divergenza: ora l’informativa dichiara troppo, che è l’errore più sicuro ma resta un errore.

Ognuna di queste finisce in un file di build: build.gradle, AndroidManifest.xml, Podfile, Package.swift, Info.plist, pubspec.yaml, package.json. È questo che la rende verificabile.

L’approccio: un registro, e un controllo a ogni pull request

1. Quando le tue pagine vengono scritte, registra da cosa sono state scritte: gli SDK, i tipi di dati e i permessi presenti nella build in quel momento.
2. A ogni pull request, rileggi i file di build e confronta.
3. Quando qualcosa è diverso, indica cosa, dove (file e riga) e quale pagina o modulo potrebbe riguardare.

Contano due proprietà. Il controllo deve leggere solo i file di build, mai il codice sorgente, mai i segreti, così è sicuro eseguirlo su qualsiasi repository. E deve dire «potrebbe essere obsoleto», non «violazione»: una libreria in un file di build non dimostra che l’app la usi, e solo tu sai se cambia ciò che la tua app raccoglie.

Configurarlo con AppFoyer

Il controllo è gratuito in ogni piano. Legge solo i file di build, non richiede chiavi né segreti, non invia nulla da nessuna parte e non modifica mai una pagina.

Con il plugin di Claude Code

1. Di’ “make this app store-ready”. Oltre a preparare le bozze delle pagine, il plugin scrive appfoyer.json alla radice del tuo repository: il registro di ciò da cui sono state scritte le pagine.
2. Di’ “add the AppFoyer drift check”. Ti mostra un workflow di GitHub e scrive .github/workflows/appfoyer.yml quando rispondi di sì.
3. Esegui il commit di entrambi i file. Il plugin non esegue mai commit né push al posto tuo.

Senza il plugin

Aggiungi il workflow tu stesso:

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

Apri una pull request. Se nel repository non c’è ancora un appfoyer.json, il job summary mostra il file che verrebbe scritto dalla tua build. Confrontalo con le tue pagine pubblicate ed eseguine il commit.

Oppure crealo in locale, con lo stesso scanner, pubblicato su npm:

npx @appfoyer/check init

Su un altro sistema di CI

Il pacchetto npm funziona ovunque giri Node 20 o successivo. Per GitLab, ad esempio:

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

--format markdown produce lo stesso report che mostra il job summary di GitHub; --format json è per gli script.

Come appare una segnalazione

Una pull request che aggiunge RevenueCat a un’app le cui pagine sono state scritte senza di esso:

"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

Per impostazione predefinita il job segnala e passa. Aggiungi fail-on-drift: "true" sotto with: per farlo fallire finché il registro non viene aggiornato.

Quando segnala una modifica

1. Aggiorna ciò che la modifica riguarda. Di’ di nuovo “make this app store-ready” sullo stesso branch: il plugin rilegge la build, aggiorna i dati dell’app, riscrive le bozze delle pagine toccate dalla modifica e riscrive appfoyer.json. Oppure modifica tu le pagine e la scheda Store forms nella dashboard.
2. Aggiorna il registro. Il plugin l’ha già fatto. Dopo una modifica dalla dashboard, esegui npx @appfoyer/check update, oppure copia il file aggiornato dal job summary, dove si trova sotto le segnalazioni.
3. Eseguine il commit nella stessa pull request. L’esecuzione successiva non mostra modifiche, e la cronologia mostra la dipendenza e l’aggiornamento dell’informativa arrivati insieme.
4. Aggiorna i moduli degli store nelle console. Né il controllo né AppFoyer possono raggiungere Play Console o App Store Connect. Le bozze delle risposte sono nella scheda Store forms della dashboard.
5. Pubblica le bozze aggiornate dalla schermata di revisione.

Più app in un solo repository

appfoyer.json contiene una voce per ogni scheda dello store. Un product flavor con il proprio application id ha la propria voce, così un SDK pubblicitario usato solo dal flavor gratuito viene confrontato con le pagine del flavor gratuito e non con quelle del flavor a pagamento. Il plugin scrive una voce per ogni flavor che ha reso pronto per gli store. A mano, una voce accetta un elenco sourceSets (["free"], oppure, per una build con più dimensioni, ogni flavor della combinazione più la combinazione stessa) e una cartella root quando l’app si trova dentro un monorepo.

Cosa non può vedere

• Le dipendenze delle dipendenze, tranne su iOS, dove Podfile.lock le elenca. Un SDK portato da un’altra libreria non compare nel tuo file di build, quindi non compare nemmeno qui.
• La configurazione solo in codice. app.config.js / app.config.ts in Expo è JavaScript e non viene letto; app.json e package.json sì.
• Se usi ciò che dichiari. Una dipendenza presente ma inutilizzata viene comunque segnalata.
• Il tuo backend. Nulla in un file di build dice cosa conserva il tuo server o per quanto tempo.

È un promemoria nel momento in cui una modifica costa meno da dichiarare, non un verdetto di conformità e non una consulenza legale.

Le fonti ufficiali

• Provide information for Google Play’s Data safety section — Guida di Google Play Console: mantenere il modulo accurato, e i dati degli SDK di terze parti
• App privacy details on the App Store — Apple: mantenere le risposte aggiornate, e aggiornarle senza un aggiornamento dell’app
• appfoyer/check-action e @appfoyer/check — l’Action e il pacchetto npm, con ciò che leggono