Les privacy manifests d’Apple décrivent les pratiques de données et les raisons approuvées d’utiliser certaines API. Le détail opérationnel qui compte : votre archive finale contient votre code et chaque dépendance. Une cible d’app propre peut quand même échouer à cause d’un SDK embarqué.

Ce qui appartient à un privacy manifest

Un fichier PrivacyInfo.xcprivacy peut déclarer les données collectées, les domaines de tracking et l’usage des API à required reason. Le manifest est de la donnée structurée : éditez-le comme une property list et validez les clés, au lieu de le traiter comme du texte libre de release.

Auditez le graphe final de dépendances

  1. Produisez une archive Release avec la même configuration que pour la soumission App Store.
  2. Listez chaque framework et SDK embarqué, dépendances transitives comprises.
  3. Vérifiez si Apple en liste comme SDK tiers couramment utilisés soumis à exigences de manifest et de signature.
  4. Mettez à jour ou remplacez les versions non conformes avant de modifier vos propres déclarations pour compenser.
Ne devinez pas un code de raison

Chaque API à required reason doit correspondre à une raison approuvée décrivant fidèlement l’usage qu’en font l’app ou le SDK.

Gardez les trois surfaces de confidentialité alignées

Votre manifest, les réponses de confidentialité d’App Store Connect et le comportement du binaire décrivent des choses liées mais différentes. Relisez les trois ensemble dès qu’analytics, publicité, création de compte, diagnostics ou un SDK tiers change.

Ce que le manifest ne remplace pas

Un privacy manifest ne remplace ni les purpose strings des permissions système dans Info.plist, ni l’étiquette de confidentialité d’App Store Connect, ni votre politique de confidentialité publique. Chaque surface a son audience. Elles doivent s’accorder sur le comportement sans devenir des copies du même texte.

Tableau de bord analytics d’Uprate montrant les notes App Store et Google Play, les métriques d’avis et les avis de connexion API

Les données du store et le comportement en production doivent raconter la même histoire de confidentialité.

Porte de release

  • L’archive Release contient les manifests attendus.
  • Chaque API à required reason a une raison approuvée exacte.
  • Les SDK listés respectent les exigences actuelles de manifest et de signature d’Apple.
  • Les domaines de tracking et les déclarations de données collectées correspondent à la production.
  • Les réponses de confidentialité d’App Store Connect ont été relues après un changement de dépendances.

Si App Store Connect signale le téléversement

Utilisez le message comme un pointeur vers le framework, la catégorie d’API ou la déclaration manquante. Corrigez la source du problème et téléversez un nouveau build. Conservez l’archive rejetée et le lockfile de dépendances pour que l’équipe puisse reproduire ce qui a réellement été soumis.

Cet article vous a-t-il aidé ?