LaunchLint Academy
La réponse courte
- PrivacyInfo.xcprivacy déclare des pratiques et les raisons approuvées pour certaines Required Reason APIs.
- Dans React Native et Expo, les accès viennent souvent des dépendances natives. Vérifiez SDK, Pods et rapport Xcode final.
- Le manifest ne remplace ni App Privacy, ni politique de confidentialité, ni le consentement ATT lorsqu’il s’applique.
1. Ce que décrit PrivacyInfo.xcprivacy
Apple utilise des manifests lisibles par machine pour apps et SDK. Xcode peut agréger ceux des tiers afin d’examiner les pratiques incluses et préparer App Privacy.
Le fichier peut contenir données collectées, domaines de tracking et Required Reason APIs. Toutes les clés ne concernent pas toutes les apps ; copier un modèle crée des affirmations techniques.
| Couche | Rôle | Remplace ? |
|---|---|---|
| Manifest | Déclaration bundle | Non |
| Rapport Xcode | Agrégation | Non |
| App Privacy | Déclaration publique | Non |
| politique de confidentialité | Traitement et droits | Non |
2. Required Reason APIs : une raison réelle
UserDefaults, timestamps, boot time, espace disque ou clavier actif peuvent nécessiter une raison approuvée. Apple peut étendre la liste ; consultez la version actuelle.
Le code n’est pas un texte libre ni un correctif cosmétique. Il doit correspondre à l’usage réel ; sinon corrigez l’implémentation ou la dépendance.
3. Les SDK tiers font partie de la soumission
Apple maintient une liste de SDK soumis à manifest et signature dans certains cas. Les stacks React Native incluent parfois Hermes, Firebase, GoogleUtilities, Protobuf, OneSignal ou SDWebImage.
Vous restez responsable. Préférez une version avec manifest fournisseur correct et ne masquez pas un manifest obsolète avec un fichier global.
- Inventorier dépendances natives
- Comparer la liste Apple
- Lire docs et releases
- Localiser le manifest
- Vérifier signature
- Supprimer modules inutiles
- Régénérer le rapport
4. Configurer avec Expo et React Native
Avec CNG, utilisez expo.ios.privacyManifests. En bare React Native, créez le fichier dans Xcode et associez le bon target. Une OTA JavaScript ne suffit pas.
{
"expo": {
"ios": {
"privacyManifests": {
"NSPrivacyAccessedAPITypes": [
{
"NSPrivacyAccessedAPIType":
"NSPrivacyAccessedAPICategoryUserDefaults",
"NSPrivacyAccessedAPITypeReasons": ["CA92.1"]
}
]
}
}
}
}Ce n’est pas un modèle universel. Vérifiez CA92.1 et chaque code avec la documentation actuelle et la configuration production résolue.
- Résoudre production
- Valider les clés
- Relier raison et usage
- Bon target
- Nouveau binaire
- Augmenter le build
5. Le bundle final est la preuve
Un fichier du fichiers du projet montre une intention. L’archive contient Pods, frameworks et ressources. Lisez le rapport Xcode et les manifests agrégés ; Expo documente des limites avec certaines dépendances statiques.
Vérifiez app, extensions, widgets et notification extensions. Conservez rapport, build et lockfile.
- Archive Release
- Tous les targets
- Rapport agrégé
- Types ou domaines inattendus
- Raisons contre usages
- Warning liée au build
- Fix dans nouvel artefact
6. Manifest, App Privacy et ATT sont distincts
App Privacy est publique ; le manifest est technique. Un manifest SDK ne décrit pas seul votre backend ni le comportement dynamique et ne génère pas le formulaire complet.
ATT est une autre couche. NSPrivacyTracking n’accorde aucune permission et le dialogue ATT ne remplace pas le label.
7. Corriger systématiquement
Reliez warning, catégorie et module. Vérifiez code natif, Pods, frameworks, mises à jour et finalité avant de changer le manifest.
LaunchLint inventorie fichiers, config, versions et catégories sans exécuter de build. La tâche distingue preuve fichiers du projet et validation manuelle du bundle.
- Conserver warning et build
- Identifier module
- Valider raison
- Mettre à jour ou retirer SDK
- Manifest minimal
- Nouveau release
- Rapport et upload
- Mettre à jour label et politique de confidentialité
8. Preflight avant l’upload
Figez lockfile et configuration production avant l’archive. Construisez depuis le commit prévu, notez le build number et ne confondez pas un avertissement d’un ancien upload avec le nouvel artefact. Après toute modification de Pod, plugin ou target, recommencez la vérification.
Lisez le Privacy Report comme une série de questions : reconnaissez-vous chaque SDK, catégorie, domaine et raison ? Étudiez l’inattendu avant la soumission. Comparez ensuite avec App Privacy et la politique de confidentialité, y compris le backend que le manifest ne décrit pas. Une approbation précédente ne valide pas la nouvelle combinaison.
Checklist finale :
- Commit et lockfile identifiés
- Configuration production résolue
- Tous les targets archivés
- Rapport agrégé relu
- Raisons liées aux usages
- SDK Apple à jour
- App Privacy et politique de confidentialité comparées
- Build exact dans TestFlight
- Emails de validation vérifiés
- Preuves conservées
9. Erreurs qu’un manifest valide n’empêche pas
Un plist valide peut rester faux : raisons copiées d’une autre app, catégories absentes du build, fichier global masquant un SDK ancien, extension oubliée ou configuration production différente. La validation de syntaxe ne prouve ni l’usage réel ni la présence dans le bon target.
Évitez aussi de traiter une couche comme vérité complète : modifier App Privacy sans relire le bundle, corriger le manifest sans la politique de confidentialité ou croire qu’ATT couvre tout tracking. Une personne compare les couches et une seconde relit l’archive afin de ne pas dépendre seulement de l’auteur du fix.
Bloquer la soumission si :
- Raison sans usage précis
- Version SDK inconnue
- Extension non vérifiée
- Domaine inattendu
- Warning d’un autre build
- Changement natif livré en OTA
- Label et politique de confidentialité divergents
- Rapport non conservé
Questions fréquentes
Toute app a-t-elle besoin de son manifest ?
Pas avec les mêmes entrées. Cela dépend des APIs et SDK du bundle final.
Puis-je copier les reason codes ?
Non. Ils doivent correspondre à l’usage approuvé réel.
Le manifest remplace App Privacy ?
Non. Ce sont des couches distinctes avec politique de confidentialité et ATT. Le formulaire public couvre aussi le backend et les finalités absentes du manifest technique.
Une OTA suffit-elle ?
Non. Le manifest fait partie du binaire natif.