Mantener tu política de privacidad sincronizada con tu build

Escribir una política de privacidad es un trabajo de una sola vez. Mantenerla verdadera no lo es: la política describe el build que tenías cuando la escribiste, y el build no deja de cambiar. Un pull request añade reporte de fallos, una biblioteca de suscripciones o un permiso de ubicación, la app se publica, y la política, el formulario de Data safety y los detalles de App Privacy siguen describiendo la app antigua.

Ambas tiendas lo tratan como problema tuyo, no suyo. Google Play dice que tus respuestas de Data safety deben ser exactas y completas en todo momento, y que los datos que recopilan las bibliotecas y los SDK de terceros de tu app te corresponde declararlos a ti. Apple dice lo mismo de los detalles de App Privacy, y añade que puedes cambiar las respuestas en App Store Connect en cualquier momento sin enviar una actualización.

De dónde viene realmente el desfase

Casi nunca de una decisión de «recopilar más datos». Viene del trabajo de ingeniería normal:

• Una dependencia nueva. Reporte de fallos, analítica, un SDK de paywall, una biblioteca de mapas.
• Un permiso nuevo. Ubicación para una función, la cámara para un escáner, rastreo para anuncios.
• Un flavor o un target. Un build gratuito incorpora un SDK de anuncios que el build de pago no tiene.
• Una eliminación. También es desfase: ahora la política declara de más, que es el error más seguro pero sigue siendo un error.

Cada uno de estos cambios acaba en un archivo de build: build.gradle, AndroidManifest.xml, Podfile, Package.swift, Info.plist, pubspec.yaml, package.json. Eso es lo que hace que se pueda comprobar.

El enfoque: un registro y una comprobación en cada pull request

1. Cuando se escriben tus páginas, registra a partir de qué se escribieron: los SDK, los tipos de datos y los permisos que había en el build en ese momento.
2. En cada pull request, vuelve a leer los archivos de build y compara.
3. Cuando algo difiere, indica qué, dónde (archivo y línea) y qué página o formulario puede verse afectado.

Hay dos propiedades importantes. La comprobación debe leer solo archivos de build —nunca código fuente, nunca secretos—, para que se pueda ejecutar con seguridad en cualquier repositorio. Y debe decir «puede estar desactualizado», no «infracción»: una biblioteca en un archivo de build no demuestra que la app la use, y solo tú sabes si cambia lo que recopila tu app.

Configurarlo con AppFoyer

La comprobación es gratuita en todos los planes. Solo lee archivos de build, no necesita clave ni secreto, no envía nada a ningún sitio y nunca cambia una página.

Con el plugin de Claude Code

1. Di “make this app store-ready” (prepara esta app para las tiendas). Además de redactar las páginas, el plugin escribe appfoyer.json en la raíz de tu repositorio: el registro de a partir de qué se escribieron las páginas.
2. Di “add the AppFoyer drift check” (añade la comprobación de desfase de AppFoyer). Te muestra un workflow de GitHub y escribe .github/workflows/appfoyer.yml cuando dices que sí.
3. Haz commit de ambos archivos. El plugin nunca hace commit ni push por ti.

Sin el plugin

Añade el workflow tú mismo:

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

Abre un pull request. Si todavía no hay appfoyer.json en el repositorio, el resumen del job muestra el archivo que escribiría a partir de tu build. Compáralo con tus páginas publicadas y haz commit.

O créalo en local, con el mismo escáner, publicado en npm:

npx @appfoyer/check init

En otro sistema de CI

El paquete de npm funciona en cualquier sitio donde funcione Node 20 o posterior. Para GitLab, por ejemplo:

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

--format markdown da el mismo informe que muestra el resumen del job de GitHub; --format json es para scripts.

Cómo se ve un hallazgo

Un pull request que añade RevenueCat a una app cuyas páginas se escribieron sin él:

"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 defecto, el job informa y pasa. Añade fail-on-drift: "true" bajo with: para que falle hasta que se actualice el registro.

Cuando informa de un cambio

1. Actualiza lo que afecta el cambio. Vuelve a decir “make this app store-ready” en la misma rama: el plugin vuelve a leer el build, actualiza los datos de la app, vuelve a redactar las páginas afectadas por el cambio y reescribe appfoyer.json. O edita tú mismo las páginas y la pestaña Store forms en el panel.
2. Actualiza el registro. El plugin ya lo hizo. Después de una edición en el panel, ejecuta npx @appfoyer/check update, o copia el archivo actualizado del resumen del job, donde aparece debajo de los hallazgos.
3. Haz commit en el mismo pull request. La siguiente ejecución no muestra cambios, y el historial muestra la dependencia y el cambio de divulgación llegando juntos.
4. Actualiza los formularios de las tiendas en las consolas. Ni la comprobación ni AppFoyer pueden acceder a Play Console ni a App Store Connect. Los borradores de respuestas están en la pestaña Store forms del panel.
5. Publica los borradores actualizados desde la pantalla de revisión.

Varias apps en un repositorio

appfoyer.json contiene una entrada por ficha de tienda. Un product flavor con su propio application id tiene su propia entrada, así que un SDK de anuncios que solo usa el flavor gratuito se compara con las páginas del flavor gratuito y no con las del de pago. El plugin escribe una entrada por cada flavor que preparó para las tiendas. A mano, una entrada lleva una lista sourceSets —["free"], o en un build con varias dimensiones cada flavor de la combinación más la propia combinación— y una carpeta root cuando la app está dentro de un monorepo.

Lo que no puede ver

• Las dependencias de las dependencias, salvo en iOS, donde Podfile.lock las enumera. Un SDK que trae otra biblioteca no aparece en tu archivo de build, así que tampoco aparece aquí.
• La configuración que solo existe como código. app.config.js / app.config.ts en Expo es JavaScript y no se lee; app.json y package.json sí.
• Si usas lo que declaras. Una dependencia presente pero sin usar se informa igualmente.
• Tu backend. Nada en un archivo de build dice qué guarda tu servidor ni durante cuánto tiempo.

Es un recordatorio en el momento en que un cambio es más barato de declarar, no un veredicto de cumplimiento ni asesoramiento legal.

Las fuentes oficiales

• Provide information for Google Play’s Data safety section — Ayuda de Google Play Console: mantener el formulario exacto y los datos de SDK de terceros
• App privacy details on the App Store — Apple: mantener las respuestas actualizadas y cambiarlas sin actualizar la app
• appfoyer/check-action y @appfoyer/check — la Action y el paquete de npm, con lo que leen