LaunchLint Academy
La respuesta breve
- PrivacyInfo.xcprivacy declara prácticas de privacidad y razones aprobadas para ciertas Required Reason APIs.
- En React Native y Expo muchos accesos vienen de dependencias nativas. Revisa SDKs, Pods y el Privacy Report del archive final.
- El manifest no sustituye App Privacy, política de privacidad ni el consentimiento ATT cuando corresponda.
1. Qué describe PrivacyInfo.xcprivacy
Apple creó manifests legibles por máquina para apps y SDKs. Xcode puede agregar los manifests de terceros y ayudar a preparar respuestas App Privacy más precisas.
Puede contener datos recogidos, dominios de tracking, tracking y Required Reason APIs. No todas las claves corresponden a todas las apps; copiar una plantilla crea afirmaciones técnicas posiblemente falsas.
| Capa | Función | ¿Sustituye? |
|---|---|---|
| Manifest | Declaración del bundle | No |
| Xcode report | Agrega manifests | No |
| App Privacy | Declaración pública | No |
| política de privacidad | Explica tratamiento y derechos | No |
2. Required Reason APIs necesitan un motivo real
Categorías como UserDefaults, timestamps, boot time, espacio de disco o teclado activo pueden requerir un reason aprobado. Apple puede ampliar la lista; consulta la versión vigente.
El código no es texto libre ni un parche. Debe coincidir con el uso real. Si el SDK usa la API para otro fin, corrige implementación o dependencia.
3. Los SDKs de terceros forman parte del envío
Apple mantiene una lista de SDKs con requisitos de manifest y firma en ciertos casos. En stacks React Native aparecen indirectamente Hermes, Firebase, GoogleUtilities, Protobuf, OneSignal o SDWebImage.
Sigue siendo tu responsabilidad. Prefiere actualizar a una versión con manifest del proveedor y no ocultes declaraciones incorrectas con un archivo global.
- Inventariar dependencias nativas
- Cruzar la lista de Apple
- Leer documentación y releases
- Localizar manifest en Pod o framework
- Revisar firma
- Eliminar módulos sin uso
- Regenerar report
4. Configurar en Expo y React Native
Con CNG usa expo.ios.privacyManifests. En bare React Native crea el archivo en Xcode y añádelo al target correcto. Es configuración nativa: OTA no basta.
{
"expo": {
"ios": {
"privacyManifests": {
"NSPrivacyAccessedAPITypes": [
{
"NSPrivacyAccessedAPIType":
"NSPrivacyAccessedAPICategoryUserDefaults",
"NSPrivacyAccessedAPITypeReasons": ["CA92.1"]
}
]
}
}
}
}No es una plantilla universal. Contrasta CA92.1 y cada código con la documentación actual y la configuración production resuelta.
- Resolver production
- Validar claves
- Relacionar reason y uso
- Target correcto
- Nuevo binario
- Subir build number
5. El bundle final es la evidencia
Un archivo del archivos del proyecto prueba intención. El archive incluye Pods, frameworks y recursos. Lee el Xcode Privacy Report e investiga qué manifests se agregaron; Expo documenta límites con dependencias estáticas.
Revisa app, extensiones, widgets y notification extensions. Conserva report, build y lockfile como evidencia.
- Archive Release
- Todos los targets
- Report agregado
- Tipos o dominios inesperados
- Reasons contra uso
- Warning ligada al build
- Fix en artefacto nuevo
6. Manifest, App Privacy y ATT no son iguales
App Privacy es pública; el manifest es técnico. El manifest de SDK no incluye por sí solo backend y comportamiento dinámico ni genera el formulario completo.
ATT es otra capa. NSPrivacyTracking no concede permiso y un diálogo ATT no sustituye la etiqueta. Revisa finalidad, vinculación y acceso tercero.
7. Corregir de forma sistemática
Asigna warning a categoría y módulo. Revisa código nativo, Pods, frameworks, updates y finalidad antes de cambiar el manifest.
LaunchLint inventaría archivos, config, versiones y categorías sin ejecutar builds. El task debe separar pruebas del archivos del proyecto y validación manual del bundle.
- Guardar warning y build
- Mapear módulo
- Validar reason
- Actualizar o eliminar SDK
- Manifest mínimo
- Nuevo release
- Revisar report y upload
- Actualizar label y política de privacidad
8. Preflight antes de subir el build
Congela el lockfile y la configuración production antes del archive. Genera el binario desde el commit previsto, registra build number y no mezcles una advertencia de un upload antiguo con el artefacto nuevo. Si cambia un Pod, plugin o target después de la revisión, repite el control completo.
Lee el Privacy Report como una lista de preguntas: ¿reconoces cada SDK, categoría, dominio y reason? Investiga lo inesperado antes de enviar. Después compara el resultado con App Privacy y la política de privacidad, incluidas prácticas del backend que el manifest no puede describir. Una aprobación previa no demuestra que la nueva combinación de dependencias siga siendo correcta.
Checklist final:
- Commit y lockfile identificados
- Configuración production resuelta
- Todos los targets archivados
- Report agregado revisado
- Reasons vinculados a uso real
- SDKs de la lista Apple actualizados
- App Privacy y política de privacidad comparadas
- Build exacto subido a TestFlight
- Emails de validación revisados
- pruebas guardada para el siguiente release
9. Errores frecuentes que un manifest válido no evita
Un plist puede ser sintácticamente válido y seguir siendo incorrecto. Ocurre al copiar reasons de otra app, declarar categorías que no usa el build o añadir un archivo propio para tapar un SDK antiguo. También falla cuando el manifest pertenece al target principal pero no a una extensión distribuida, o cuando app.config genera valores diferentes en production.
Otro error es tratar una sola capa como verdad completa: actualizar App Privacy sin revisar el bundle, corregir el manifest sin cambiar la política de privacidad o asumir que el diálogo ATT cubre cualquier tracking. Antes del submit, asigna una persona responsable de comparar las capas y una segunda persona para revisar el archive. La separación reduce confirmaciones basadas únicamente en quien implementó el cambio.
Señales para detener el envío:
- Reason sin referencia al uso concreto
- SDK requerido con versión desconocida
- Target de extensión sin revisar
- Dominio de tracking inesperado
- Warning asociado a otro build
- Cambio nativo entregado solo por OTA
- Label y política de privacidad con fines diferentes
- No existe Privacy Report guardado
Preguntas frecuentes
¿Toda app necesita manifest propio?
No con las mismas entradas. Depende de APIs y SDKs del bundle final.
¿Puedo copiar reason codes?
No. Deben corresponder al uso real aprobado por Apple.
¿Sustituye App Privacy?
No. Son capas distintas junto con política de privacidad y ATT.
¿Basta una OTA?
No. El manifest forma parte del binario nativo.