Cómo averiguar qué recopilan tus SDK

Todos los requisitos de las tiendas sobre datos se reducen a una lista, y casi nadie la pone por escrito. Tu política de privacidad, tu formulario de Data safety y tus respuestas de App Privacy son tres versiones de la misma lista, así que hacerla una vez, y bien, es todo el trabajo.

Ambas tiendas dejan claro que el comportamiento de los SDK cuenta como tuyo. Google Play dice que la recopilación de datos “includes data collected and handled through any third-party libraries or SDKs used in their apps” (incluye los datos recopilados y gestionados a través de cualquier biblioteca o SDK de terceros que usen sus apps). Apple te pide identificar los datos que “you or your third-party partners collect” (tú o tus socios externos recopilan).

Paso 1: encuentra cada SDK

Lee los archivos; no te fíes de la memoria:

Plataforma	Archivos
Android	build.gradle / build.gradle.kts, libs.versions.toml, AndroidManifest.xml (permisos, meta-data)
iOS	Podfile, Package.swift, *.pbxproj, Info.plist (textos de uso), *.entitlements
Flutter	pubspec.yaml
React Native / Expo	package.json, app.json

Incluye las dependencias transitivas que no elegiste: un SDK que arrastra una biblioteca de publicidad recopila lo que recopila esa biblioteca.

Paso 2: lee la divulgación de cada proveedor

La mayoría de los proveedores serios publican una página que dice exactamente qué envía su SDK, porque sus clientes la necesitan para estos mismos formularios. Esa página —no una entrada de blog, no una respuesta de un foro— es tu fuente.

Firebase es el ejemplo práctico, porque Google publica un desglose por producto asignado a las categorías de App Privacy de Apple:

Producto de Firebase	Qué recopila, según la documentación de Google
Analytics	ID de instancia de la app, propiedades de usuario, eventos, dirección IP
Crashlytics	Stack traces y estado de la aplicación en el momento del fallo, información del dispositivo y del SO, más cualquier clave personalizada, log e ID de usuario que adjuntes tú
Cloud Messaging	El token de push asociado a un ID de instalación de la app; modelo del dispositivo, idioma, zona horaria, versión del SO, identificador y versión de la app
Authentication	Los identificadores que genera, más direcciones de correo, números de teléfono y nombres visibles de los proveedores de inicio de sesión que actives
Performance Monitoring	Métricas de rendimiento como el tiempo de arranque y la latencia de red, información del dispositivo y del SO, dirección IP para la segmentación geográfica
Remote Config	Código de país e idioma, zona horaria, versión del SO, identificadores de la app y del bundle

Lee esa tabla dos veces si usas Crashlytics: la última columna depende en parte de ti. Las claves personalizadas y los ID de usuario que adjuntas a los informes de fallos son datos que decidiste enviar, y deben figurar en tu política con tus propias palabras.

Otros proveedores con divulgaciones publicadas a los que vale la pena acudir directamente: redes publicitarias (AdMob, AppLovin, Unity, ironSource), herramientas de atribución (AppsFlyer, Adjust), reporte de errores (Sentry, Bugsnag), compras (RevenueCat, Adapty) y proveedores de autenticación.

Paso 3: cuando el proveedor no publica nada

Ocurre, sobre todo con bibliotecas más pequeñas. En ese caso:

• Lee el tráfico de red. Pasa la app por un proxy y mira qué envía el SDK. Es el único método indiscutible, y resuelve la cuestión en una tarde.
• Lee el código fuente, si es abierto.
• Pregunta al proveedor por escrito y guarda la respuesta.
• Plantéate quitarlo. Una dependencia cuyo comportamiento con los datos nadie quiere declarar es un riesgo que cargas por la comodidad de otro.

Paso 4: convierte la lista en los tres documentos

Una lista, tres versiones, en este orden:

1. La política de privacidad: categorías, finalidades, terceros con nombre, conservación, contacto.
2. El formulario de Data safety en Play Console: los mismos datos como casillas.
3. App Privacy en App Store Connect: los mismos datos otra vez, con las categorías de Apple.

Rellénalos a partir de la lista, nunca unos a partir de otros. Donde dos no coinciden, la tienda cree al SDK: Google Play indica que “when Google becomes aware of a discrepancy between your app behavior and your declaration, we may take appropriate action, including enforcement action” (cuando Google detecta una discrepancia entre el comportamiento de tu app y tu declaración, podemos tomar las medidas oportunas, incluidas medidas de cumplimiento).

Mantenerla al día

El hecho que invalida los tres es siempre el mismo: cambió una dependencia. Pon una línea en tu checklist de publicación —¿cambió alguna dependencia en esta versión? Si es así, revisa de nuevo la política y los dos formularios—, porque ambas tiendas exigen que sigan siendo exactos, no solo que lo fueran en el lanzamiento.

Qué hace AppFoyer aquí

Este método es lo que automatiza nuestro agente. Apunta un agente de programación al repositorio y leerá esos archivos de dependencias, cotejará lo que encuentre con un mapa de SDK conocidos y redactará la política de privacidad nombrando a los terceros que encontró, indicando el archivo y la línea de donde salió cada dato, para que puedas comprobarlo en lugar de fiarte. Sin agente, un formulario corto hace las mismas preguntas.

Lo que produce es un borrador que tú revisas. No puede ver una biblioteca que no reconoce, y nunca publica nada sin tu clic.

Las fuentes oficiales

• Privacidad y seguridad en Firebase y Recopilación de datos para el App Store — Google. La tabla de arriba procede de estas páginas; la autoridad son ellas, no esta.
• Proporcionar información para la sección Data safety de Google Play — Ayuda de Google Play Console
• Detalles de privacidad de las apps en el App Store — Apple