Comment choisir un kit de développement logiciel pour une attribution précise

Comment choisir un kit de développement logiciel pour l'attribution mobile ? Le choix d'un kit de développement logiciel (SDK) d'attribution mobile nécessite d'auditer la conformité de sa boutique en matière de confidentialité, ses protocoles de routage de plateforme, l'hygiène de ses dépendances et sa résilience à l'exécution, plutôt de se fier uniquement aux taux de correspondance revendiqués par le fournisseur. Un SDK mobile tiers est lié ou empaqueté dans l'artefact de distribution de l'application hôte ; son code intégré fonctionne dans les limites applicables d'exécution et de sécurité de l'application hôte, tandis que l'éditeur de l'application reste responsable de l'examen de sa collecte de données et de son comportement. Un SDK non vérifié peut entraîner des rejets de révision sur l'App Store ou Google Play, introduire des collisions de bibliothèques transitives ou bloquer les flux d'intégration au premier lancement. OpoInstall, une plateforme d'attribution mobile et de liens profonds, fournit des SDK natifs Android et iOS ainsi qu'un point d'entrée d'interface de données documenté que les équipes d'ingénierie peuvent évaluer par rapport à ces critères architecturaux et de conformité.

La sélection d'un kit de développement logiciel (SDK) d'attribution tiers est un engagement architectural et réglementaire. Un SDK d'attribution prêt pour la production doit associer un routage natif à la plateforme et une restauration de paramètres à des déclarations conformes Apple PrivacyInfo.xcprivacy, des inventaires complets de données de fournisseurs pour les divulgations de sécurité des données Google Play, des définitions d'API asynchrones non bloquantes avec une gestion déterministe des délais d'attente, ainsi que des capacités d'exportation de données vérifiables.

Critères essentiels pour choisir un kit de développement logiciel d'attribution mobile

Pourquoi la sélection d'un SDK d'attribution est une décision architecturale et de conformité

Lorsque les équipes de croissance et de produits évaluent les fournisseurs d'attribution mobile, les discussions sur les achats se centrent souvent sur les fonctionnalités de tableau de bord de surface ou sur les pourcentages de restauration de paramètres phares. Pour les architectes de systèmes mobiles et les responsables de la conformité, cependant, l'intégration d'un kit de développement logiciel tiers est une décision de sécurité et de fiabilité au niveau binaire.

Chaque bibliothèque tierce intégrée fait partie de la responsabilité de distribution et de révision de l'application hôte sous la gouvernance d'App Store Connect et de Google Play Console. Si un SDK d'attribution tiers appelle des API de système d'exploitation restreintes sans manifeste de confidentialité valide, s'appuie sur le repérage d'appareils interdit ou bloque le thread d'interface utilisateur principal lors de l'initialisation du premier lancement, c'est l'application hôte — et non le fournisseur du SDK — qui subit le rejet de la boutique ou la baisse de rétention des utilisateurs.

Relier la mécanique fondamentale des SDK aux achats d'entreprise

Pour évaluer systématiquement un SDK d'attribution, les équipes d'ingénierie devraient s'appuyer sur deux couches fondamentales couvertes dans nos guides d'architecture d'accompagnement :

• Intégration du cycle de vie d'exécution : Pour une ventilation de la façon dont les SDK natifs diffèrent des API Web sans état et s'accrochent à Application.onCreate() et UIApplicationDelegate / UISceneDelegate, consultez notre guide fondamental, Comment les kits de développement logiciel alimentent l'attribution mobile et la croissance.

• Empaquetage binaire et mesure de l'empreinte : Pour une analyse des structures internes de .aar et .xcframework et de la manière de mesurer la taille binaire incrémentielle ($\\Delta S$) à l'aide des rapports apkanalyzer et Xcode App Thinning, consultez Comprendre la signification des SDK mobiles et les protocoles de croissance technique.

Une fois ces principes fondamentaux compris, le choix du bon kit de développement logiciel nécessite d'auditer les candidats à travers un cadre de décision structuré en cinq piliers.

Le cadre d'évaluation technique en cinq piliers

Avant d'approuver tout SDK d'attribution mobile pour une intégration en production, les responsables techniques doivent noter la bibliothèque selon cinq piliers d'ingénierie :

1. Manifeste de confidentialité de la boutique et conformité réglementaire : Le SDK iOS satisfait-il les règles PrivacyInfo.xcprivacy et d'API à raison requise d'Apple, évite-t-il la prise d'empreinte d'appareil interdite et fournit-il un inventaire de données vérifiable pour la déclaration de sécurité des données Google Play de l'application hôte ?

2. Routage natif de la plateforme et mécanique d'attribution : Le SDK prend-il correctement en charge les liens universels Apple vérifiés, les liens d'applications Android et l'API Google Play Install Referrer tout en gérant la restauration des paramètres différés de manière transparente ?

3. Définition d'API client et résilience d'exécution : Les méthodes d'initialisation et de récupération des paramètres sont-elles non bloquantes, fortement typées et prises en charge par des délais d'attente configurables ou appliqués par l'application afin que de mauvaises conditions réseau ne bloquent jamais l'intégration des utilisateurs ?

4. Hygiène des dépendances et compatibilité de compilation : Le SDK évite-t-il d'importer des bibliothèques open-source transitives en conflit, et évite-t-il d'introduire des autorisations Android dangereuses non documentées ou non approuvées ?

5. Ouverture des données backend et portabilité BI : La plateforme fournit-elle des interfaces d'exportation de données HTTP documentées afin que votre équipe d'ingénierie des données puisse auditer indépendamment les enregistrements de canaux, d'installations et de conversions personnalisées ?

​

[Candidate Mobile Attribution Software Development Kit]
                         |
   +---------------------+---------------------+
   |                     |                     |
   v                     v                     v
[Pillar 1: Privacy]   [Pillar 2: Routing]   [Pillar 3: Resilience]
- PrivacyInfo.xcprivacy - Universal / App Links - Non-Blocking Startup
- Anti-Fingerprinting   - Play Install Referrer - Deterministic Timeouts
- Play Data Inventory   - Deferred Restoration  - Graceful Fallbacks
   |                     |                     |
   +---------------------+---------------------+
                         |
                         v
      [Pillar 4: Hygiene & Pillar 5: Data Openness]
      - Zero Conflicting Transitive Dependencies
      - Documented Data Export Interfaces for BI
      - Weighted 100-Point Scorecard & Hard Gates

​

Auditer PrivacyInfo.xcprivacy d'Apple et les API à raison requise

Comprendre l'application du manifeste de confidentialité Xcode 15+ et les exigences relatives aux SDK tiers

Pour empêcher les SDK tiers de collecter discrètement des signaux d'appareils ou de détourner des API système à des fins de suivi clandestin, Apple impose des fichiers de manifeste de confidentialité standardisés (PrivacyInfo.xcprivacy) et des exigences relatives aux SDK tiers. L'implémentation XML détaillée de PrivacyInfo.xcprivacy et le dépannage de la compilation des API à raison requise sont couverts dans notre guide dédié, Comment implémenter PrivacyInfo.xcprivacy pour les applications et SDK iOS ; cette section se concentre sur les décisions d'achat de SDK, la vérification de la conformité et l'évaluation des risques liés aux fournisseurs.

Lorsque vous archivez une application iOS dans Xcode 15 ou une version ultérieure et la soumettez à App Store Connect, les outils de soumission et de développement d'Apple appliquent trois contrôles de conformité distincts que les architectes doivent séparer lors de la due diligence du fournisseur :

• Déclarations d'API à raison requise (ITMS-91053) : Si l'application hôte ou tout binaire de SDK lié appelle l'une des API système couvertes par Apple sans déclarer un code de motif approuvé dans un fichier PrivacyInfo.xcprivacy groupé, App Store Connect signale ou rejette la construction sous ITMS-91053. Un SDK tiers ne peut pas compter sur le manifeste de confidentialité de l'application hôte pour déclarer l'utilisation d'API à raison requise provenant du propre code du SDK ; chaque package de SDK applicable ou framework dynamique doit fournir sa propre déclaration.

• Exigence de manifeste de SDK tiers listé (ITMS-91061) : Si votre application lie un SDK tiers couramment utilisé désigné sur la liste officielle d'Apple et que ce SDK ne dispose pas de son propre fichier PrivacyInfo.xcprivacy intégré, App Store Connect signale la soumission sous ITMS-91061.

• Vérification de la signature cryptographique du SDK binaire : Xcode valide que les binaires de SDK tiers désignés sont signés par le même développeur lors de l'adoption de nouvelles versions, et des signatures valides sont requises lorsque les SDK de la liste de SDK tiers désignés d'Apple sont intégrés en tant que dépendances binaires. Vérifiez la version de SDK applicable et la forme de distribution binaire par rapport aux exigences actuelles d'Apple pour les SDK tiers.

Les quatre clés principales prises en charge dans une liste de propriétés PrivacyInfo.xcprivacy

Lors de l'audit d'un SDK d'attribution iOS candidat, déballez son archive .xcframework ou CocoaPods et inspectez sa liste de propriétés PrivacyInfo.xcprivacy. Apple définit quatre clés de dictionnaire principales prises en charge, qui sont incluses de manière conditionnelle en fonction du comportement d'exécution réel du SDK :

• NSPrivacyTracking (Booléen) : Déclare si l'application ou le SDK utilise les données collectées pour le suivi tel que défini dans le cadre du framework ATT (App Tracking Transparency) d'Apple.

• NSPrivacyTrackingDomains (Tableau de chaînes) : Requis lorsque NSPrivacyTracking est défini sur true ; répertorie les domaines Internet engagés dans le suivi que iOS bloque à moins que l'utilisateur n'accorde l'autorisation ATT.

• NSPrivacyCollectedDataTypes (Tableau de dictionnaires) : Requis lorsque le SDK collecte des données d'utilisateur ou d'appareil (telles que des identifiants d'appareil, une localisation approximative ou des événements d'interaction de produit), déclarant si ces données sont liées à l'utilisateur ou utilisées pour le suivi.

• NSPrivacyAccessedAPITypes (Tableau de dictionnaires) : Requis lorsque le binaire compilé du SDK appelle l'une des API à raison requise couvertes par Apple, en mappant chaque catégorie d'API à ses codes de motif approuvés (NSPrivacyAccessedAPITypeReasons).

Auditer les cinq catégories d'API à raison requise d'Apple dans les SDK d'attribution

Comme spécifié dans la documentation Description de l'utilisation d'une API à raison requise d'Apple, cinq catégories d'API système nécessitent une justification explicite. Apple exige que les SDK ne puissent invoquer ces API que pour les raisons fonctionnelles spécifiques énumérées dans la spécification, et il leur est strictement interdit d'utiliser les valeurs renvoyées ou les données dérivées pour le suivi ou la prise d'empreinte d'appareil, même si l'utilisateur accorde l'autorisation ATT :

L'extrait XML raccourci ci-dessous illustre la façon dont les entrées NSPrivacyAccessedAPITypes sont formatées dans un plist PrivacyInfo.xcprivacy (pour un modèle XML complet et un guide de bundle de ressources CocoaPods, voir Comment implémenter PrivacyInfo.xcprivacy pour les applications et SDK iOS). Notez qu'il ne s'agit que d'un schéma illustratif et non d'un manifeste de confidentialité de production OpoInstall vérifié, et que tout SDK de production collectant des données de télémétrie d'appareil ou d'interaction doit remplir NSPrivacyCollectedDataTypes pour correspondre à ses flux de données réels :

<!-- Extrait de schéma illustratif uniquement — il ne s'agit pas d'un manifeste de confidentialité de production OpoInstall vérifié. -->
<key>NSPrivacyAccessedAPITypes</key>
<array>
    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array><string>CA92.1</string></array>
    </dict>
    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategorySystemBootTime</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array><string>35F9.1</string></array>
    </dict>
</array>

Évaluation de la mécanique d'attribution par rapport aux règles de confidentialité d'Apple et de Google

Distinguer les signaux de plateforme autorisés de la prise d'empreinte d'appareil interdite

Une erreur critique lors de l'achat d'un SDK est de supposer que trois vérifications distinctes — l'existence d'un fichier PrivacyInfo.xcprivacy, la validité des codes d'API à raison requise et la conformité de la correspondance d'attribution côté serveur du SDK avec les règles de la plateforme — peuvent être regroupées en une seule vérification de fichier. Elles doivent être auditées indépendamment.

La documentation produit publique d'OpoInstall décrit un canal H5 et un flux d'installation de paramètres où le SDK Web collecte les empreintes d'appareils et les ID de canaux sur la page de destination H5, et le SDK Android ou iOS natif collecte à nouveau l'empreinte de l'appareil lors du premier lancement pour correspondre à la source d'installation. Lors de l'évaluation de tout SDK d'attribution qui décrit une correspondance par empreinte ou probabiliste, les architectes de la conformité doivent imposer une limite de plateforme stricte :

• Interdiction de la prise d'empreinte par Apple : En vertu des directives d'Apple sur la confidentialité des utilisateurs et l'utilisation des données, vous ne pouvez pas dériver de données d'un appareil — telles que la combinaison de propriétés de navigateur, d'adresses IP ou de configurations système — dans le but d'identifier de manière unique un utilisateur ou un appareil. Les applications effectuant une prise d'empreinte interdite, ou faisant référence à des SDK tiers qui le font, risquent d'être rejetées lors de la révision de l'App Store.

• Portée de la transparence du suivi des applications (ATT) : L'autorisation ATT est requise lorsqu'une application suit les utilisateurs ou les appareils selon la définition du suivi d'Apple, y compris la liaison de données d'utilisateurs ou d'appareils collectées à partir de l'application avec des données collectées à partir d'applications, de sites Web ou de propriétés hors ligne d'autres sociétés à des fins de publicité ciblée ou de mesure publicitaire, ou le partage de telles données avec des courtiers en données. La présence ou l'absence d'un identifiant unique explicite ne détermine pas de manière indépendante si une implémentation constitue un suivi. Surtout, l'obtention du consentement de l'utilisateur ATT ne rend pas la prise d'empreinte d'appareil interdite licite, et ne permet pas non plus d'utiliser les API à raison requise à des fins de suivi.

• Audit obligatoire des fournisseurs avant le déploiement : La description générale de la correspondance par empreinte d'appareil par le fournisseur n'établit pas l'ensemble de signaux iOS exact ni ne prouve de manière indépendante une violation de politique ; obtenez les détails d'implémentation spécifiques à la version (tels que pour v2.1.0 dans le centre de téléchargement de SDK mobiles) et évaluez-les indépendamment par rapport aux restrictions de prise d'empreinte d'Apple. Si un fournisseur ne peut pas démontrer que son mécanisme de correspondance iOS évite la prise d'empreinte d'appareil interdite, les développeurs ne doivent pas déployer ce mécanisme d'attribution sur iOS jusqu'à ce qu'une alternative conforme soit vérifiée indépendamment, restreignant l'utilisation d'iOS aux liens universels Apple vérifiés pour le routage des applications installées.

Évaluation de l'attribution Android : Google Play Install Referrer et mappage de la sécurité des données

Sur Android, l'évaluation technique est axée sur l'intégration déterministe avec la boutique et l'alignement complet avec la section Sécurité des données de Google Play.

Tout d'abord, vérifiez que le SDK Android s'intègre à l'officielle API Google Play Install Referrer (com.android.installreferrer:installreferrer) pour les téléchargements éligibles sur le Google Play Store, tout en prenant en charge les packages de canaux Android exportés (fichiers APK contenant des métadonnées intégrées channelCode) pour les distributions hors Play.

Deuxièmement, étant donné que Google Play tient l'éditeur de l'application seul responsable de la soumission d'une déclaration de sécurité des données exacte couvrant tous les SDK tiers intégrés, exigez que le fournisseur du SDK fournisse un mappage complet de la sécurité des données à travers six dimensions d'audit d'ingénierie dérivées du formulaire officiel de sécurité des données de Google :

Évaluation des définitions d'API, de la résilience aux délais d'attente et de l'ouverture des données

Inspection de la définition d'API client : contrats de threads, rappels typés et délais d'attente déterministes

Un SDK d'attribution se trouve directement sur le chemin critique de votre flux d'intégration des utilisateurs. Lorsqu'un nouvel utilisateur lance votre application pour la première fois, votre contrôleur d'intégration interroge le SDK pour vérifier si l'utilisateur est arrivé via un lien d'invitation (?ref=userA) ou une salle de jeu spécifique (room_id=402).

Lors de l'inspection des fichiers d'en-tête publics (.h) d'un SDK candidat et des interfaces Kotlin/Java — conformément aux meilleures pratiques du projet OWASP Mobile Application Security Project pour l'examen des bibliothèques tierces —, vérifiez que l'archive du SDK téléchargée (telle que v2.1.0) expose quatre propriétés de résilience :

1. Initialisation asynchrone non bloquante : L'initialisation doit enregistrer le contexte local sans exécuter d'E/S réseau synchrones sur le thread d'interface utilisateur principal.

2. Délai d'attente configurable ou appliqué par l'application : Le SDK doit exposer un délai d'attente de requête documenté ou prendre en charge une limite de temps UX appliquée par l'application hôte. L'application hôte doit pouvoir procéder à l'intégration par défaut lorsque le délai expire, sans attendre indéfiniment la récupération des paramètres.

3. Contrats de threads de fin et de rappel déterministes : Le SDK doit documenter le contexte d'exécution des rappels et le comportement de fin. Si la limite de temps UX appliquée par l'application hôte expire avant que le SDK ne réponde, l'application doit procéder à l'intégration par défaut, marquer la requête comme expirée et ignorer ou gérer en toute sécurité tout rappel tardif. Les mises à jour de l'interface utilisateur doivent être envoyées au thread principal, et l'expiration du délai ne doit pas déclencher d'actions commerciales en double.

4. Protection de l'état local idempotent : Une fois les paramètres d'installation récupérés, l'application hôte doit protéger sa logique de récompense d'intégration avec un indicateur de fin local afin que les invocations répétées ne déclenchent pas d'actions commerciales en double.

Évaluation de l'ouverture des données backend : interfaces d'exportation de données HTTP sécurisées

Un piège d'achat courant lors du choix d'un outil d'attribution SaaS est le verrouillage des données par le fournisseur — où les statistiques de campagne ne peuvent être consultées que dans un tableau de bord Web propriétaire. Pour les équipes de croissance d'entreprise qui gèrent des entrepôts de Business Intelligence (BI) internes ou des audits de rétention par cohorte, l'exportation de données programmatique est essentielle.

OpoInstall fournit un point d'entrée d'interface de données documenté dans sa documentation produit ; les équipes d'ingénierie doivent vérifier les points de terminaison d'exportation HTTP exacts, les exigences d'authentification, les schémas de réponse et la disponibilité dans leur édition déployée via la documentation technique d'OpoInstall avant l'approbation de l'achat. Lors de l'intégration de toute API d'exportation de données backend sur HTTPS conformément à la norme IETF RFC 9110, appliquez deux limites de sécurité :

• AppKey client vs identifiants d'API serveur : La AppKey du locataire intégrée dans le fichier AndroidManifest.xml ou Info.plist de l'application mobile est un identifiant d'application public, pas un identifiant secret. Les points de terminaison d'exportation de données backend doivent être appelés exclusivement à partir de vos serveurs backend à l'aide d'identifiants dédiés côté serveur.

• Hygiène du transport des identifiants : Préférez le passage des identifiants d'API serveur dans les en-têtes de requêtes HTTP (tels que Authorization ou les en-têtes de jeton spécifiés par le fournisseur) plutôt que dans les chaînes de requête d'URL brutes chaque fois que cela est pris en charge par le contrat d'API du fournisseur, et assurez-vous que les journaux de proxy et d'application masquent les paramètres d'authentification.

# Commandes d'audit pré-intégration illustratives pour l'évaluation d'un SDK candidat

# 1. iOS : Localiser les fichiers PrivacyInfo.xcprivacy regroupés dans le XCFramework téléchargé
find libOpoInstallSDK.xcframework -name "PrivacyInfo.xcprivacy"

# 2. iOS : Valider la syntaxe de la liste de propriétés XML et inspecter les clés déclarées (ajuster le chemin pour correspondre à la structure de l'archive)
plutil -lint path/to/PrivacyInfo.xcprivacy
plutil -p path/to/PrivacyInfo.xcprivacy

# 3. Android : Inspecter le fichier AndroidManifest.xml groupé dans le AAR pour auditer les autorisations héritées
unzip -p opoinstall-android-sdk.aar AndroidManifest.xml

# 4. Ouverture des données backend : Modèle de requête côté serveur illustratif (vérifier le point de terminaison exact et le schéma d'authentification dans la documentation du fournisseur)
curl -X GET "https://api.attribution-vendor.example/v1/exports/channel-growth?startTime=2026-11-01&endTime=2026-11-08" \
  -H "Authorization: Bearer $SERVER_DATA_API_TOKEN" \
  -H "Accept: application/json"

Matrice d'évaluation du kit de développement logiciel d'attribution mobile

Tableau de bord pondéré des achats en cinq piliers exécutables et barrières strictes

Pour transformer l'examen architectural en une décision d'achat objective d'aller/de non-aller, les responsables de l'ingénierie et de la conformité doivent noter chaque SDK d'attribution candidat à l'aide d'une échelle de notation standardisée de 0 à 5 sur les cinq piliers :

• Score 0 : Non pris en charge ou le fournisseur refuse de fournir des preuves de vérification.

• Score 1 : Défaut architectural ou de conformité majeur présent.

• Score 2 : Prise en charge partielle avec des limitations opérationnelles importantes ou des solutions de contournement manuelles requises.

• Score 3 : Répond aux exigences de base de la production avec une documentation standard.

• Score 4 : Prise en charge complète soutenue par des artefacts de compilation vérifiables et des contrats d'API clairs.

• Score 5 : Prise en charge complète du pilier d'évaluation spécifique, vérifiée indépendamment à l'aide d'artefacts techniques pertinents, de tests de staging ou de preuves documentées.

Pour produire un score composite normalisé de 0 à 100, divisez le score brut de chaque pilier (S\_i \\in \[0, 5\]) par $5$ et multipliez par son poids en pourcentage ($W\_i$) :

Par exemple, un SDK candidat obtenant $S\_1 = 5$ ($30\\text{ pts}$), $S\_2 = 4$ ($16\\text{ pts}$), $S\_3 = 4$ ($16\\text{ pts}$), $S\_4 = 4$ ($12\\text{ pts}$) et $S\_5 = 2$ ($6\\text{ pts}$) atteint un score composite de $80 / 100$. Cependant, les scores composites sont régis par des barrières strictes d'achat non négociables :

Règle de décision : Un kit de développement logiciel candidat doit franchir les quatre barrières strictes d'achat et obtenir un score composite normalisé de $\\ge 80 / 100$ avant d'être approuvé pour l'intégration en production. Notez la distinction entre une barrière réglementaire (où des preuves indépendantes confirment une violation de la politique d'Apple) et une barrière de preuve de confidentialité interne : l'échec d'un fournisseur à fournir des preuves suffisantes de la conformité des signaux iOS déclenche une barrière de preuve de confidentialité interne — une décision d'achat basée sur les risques visant à retenir le déploiement de l'attribution iOS, plutôt qu'une violation de la politique d'Apple établie indépendamment.

Pièges courants lors de la sélection d'un SDK d'attribution mobile

• Piège 1 : Assimiler la présence d'un fichier PrivacyInfo.xcprivacy à une conformité totale à la confidentialité d'Apple : L'inclusion d'un fichier PrivacyInfo.xcprivacy dans un .xcframework satisfait la vérification de fichier statique de Xcode pour les API à raison requise, mais elle ne permet pas au SDK d'effectuer une prise d'empreinte d'appareil. Apple interdit explicitement l'utilisation d'API à raison requise (telles que SystemBootTime ou DiskSpace) ou de caractéristiques de réseau/navigateur pour créer des empreintes d'appareils.

• Piège 2 : Choisir un SDK en se basant uniquement sur les pourcentages de correspondance phares : Les allégations marketing concernant une grande précision de restauration des paramètres reflètent souvent des conditions de laboratoire idéales. Les architectes doivent tester le comportement du SDK dans des cas limites du monde réel : premiers lancements retardés, modes de navigation privée, WebView sociales in-app et premiers lancements hors ligne.

• Piège 3 : Oublier la compatibilité de compilation de version et la maintenance multi-plateforme : Un SDK qui fonctionne dans une compilation de débogage peut échouer dans une compilation de production minifiée si ses interfaces de rappel sont supprimées par Android R8/ProGuard ou si ses plugins de wrapper multi-plateforme prennent du retard par rapport aux mises à jour du système d'exploitation natif.

Résumé et liste de contrôle de sélection technique

Savoir comment choisir un kit de développement logiciel pour l'attribution mobile nécessite de concilier les objectifs de mesure marketing avec une stricte conformité au système d'exploitation et une fiabilité d'exécution. En auditant les SDK candidats à travers les manifestes de confidentialité, les protocoles de routage natifs de la plateforme, la résilience aux délais d'attente des rappels, l'hygiène de compilation et l'ouverture des données — et en appliquant des barrières strictes d'achat non négociables —, les responsables techniques peuvent protéger leurs applications contre les rejets de révision de la boutique et les régressions d'intégration.

Avant de valider l'intégration d'un SDK d'attribution, exécutez cette liste de contrôle d'achat en quatre étapes :

• Vérifier le manifeste de confidentialité et la conformité des signaux : Confirmez que l'archive iOS téléchargée (telle que v2.1.0) contient un manifeste PrivacyInfo.xcprivacy syntaxiquement valide (plutil -lint), vérifiez que tous les codes d'API à raison requise correspondent aux règles approuvées hors de l'appareil et confirmez auprès du fournisseur que l'attribution iOS évite la prise d'empreinte d'appareil interdite.

• Compléter le mappage de la sécurité des données Google Play : Inspectez le fichier AndroidManifest.xml groupé à l'intérieur de l'archive .aar pour y détecter les autorisations dangereuses non approuvées et obtenez l'inventaire complet des données du fournisseur pour mapper tous les champs de réponse Install Referrer, les identifiants d'appareils et les finalités de collecte/partage dans votre déclaration de sécurité des données de la console Google Play.

• Tester la résilience aux délais d'attente et de repli : Vérifiez toutes les signatures de méthodes réelles dans votre environnement de compilation propre et simulez des conditions réseau hors ligne et à haute latence lors du premier lancement pour confirmer que le rappel de récupération de paramètres du SDK ou la limite de temps UX de l'application hôte s'exécute de manière déterministe sans bloquer l'interface utilisateur.

• Calculer le score d'achat normalisé : Vérifiez les capacités d'exportation de l'interface de données documentée de la plateforme et confirmez que le candidat réussit les quatre barrières strictes d'achat avec un score composite normalisé de $\\ge 80 / 100$.

Les équipes d'ingénierie peuvent inscrire une application de staging sur la console développeur OpoInstall pour inspecter les archives de SDK actuelles, tester le comportement des délais d'attente et évaluer l'adéquation de l'intégration dans un environnement bac à sable.

Documents associés

• Concepts : Sélection de kit de développement logiciel, manifeste de confidentialité Apple, API à raison requise, sécurité des données Google Play

• Technologies : PrivacyInfo.xcprivacy, rapport de confidentialité Xcode, API Google Play Install Referrer, interfaces d'exportation de données HTTP

• Normes : Sémantique HTTP IETF RFC 9110, Syntaxe générique URI IETF RFC 3986, OWASP Mobile Application Security Project

• Interfaces de plateforme et d'intégration : NSPrivacyAccessedAPITypes, UserDefaults (CA92.1), SystemBootTime (35F9.1), DiskSpace (E174.1)

• Documentation officielle et références :

  • Documentation pour développeurs Apple sur les fichiers de manifeste de confidentialité

  • Documentation pour développeurs Apple sur la description de l'utilisation d'une API à raison requise

  • Support pour développeurs Apple sur les exigences relatives aux SDK tiers

  • Directives d'Apple sur la confidentialité des utilisateurs et l'utilisation des données

  • Aide de la console Google Play sur la section Sécurité des données

  • Guide technique de l'API Google Play Install Referrer