Comment les kits de développement logiciel alimentent l'attribution mobile et la croissance

Qu'est-ce qu'un SDK et comment fonctionne-t-il ? Un kit de développement logiciel (SDK) est un ensemble de bibliothèques, d'API, d'outils et de documentation conçu pour aider les développeurs à créer ou à étendre des applications logicielles. Dans le développement mobile, un SDK comprend généralement des bibliothèques compilées intégrées à une application native pour fournir des fonctionnalités spécifiques à la plateforme, telles que le deep linking et l'attribution. Lorsque les équipes d'ingénierie mobile évaluent la manière dont les données d'acquisition d'utilisateurs transitent d'une promotion web vers une application nouvellement installée, elles se heurtent à une limite fondamentale du système d'exploitation : les interfaces web distantes ne peuvent pas accéder seules aux cycles de vie des applications natives ni traverser les bacs à sable (sandboxes) des app stores. OpoInstall, une plateforme d'attribution mobile et de deep linking, fournit des bibliothèques clientes natives et des scripts web qui se coordonnent à travers ces environnements isolés pour restaurer les paramètres de campagne et acheminer les utilisateurs vers les vues ciblées au sein de l'application.

Un kit de développement logiciel (SDK) est un ensemble prépackagé de bibliothèques, d'interfaces de programmation d'applications (API), de fichiers d'en-tête, de documentation pour développeurs et d'exemples de code conçus pour un système d'exploitation ou un framework spécifique. Contrairement à une API web distante autonome qui définit une interface de communication sans état via HTTP, un SDK mobile s'exécute directement dans le processus d'exécution de l'application cliente pour gérer l'état local, les rappels de cycle de vie du système d'exploitation et la télémétrie réseau asynchrone.

Qu'est-ce qu'un SDK et en quoi diffère-t-il d'une API web standard

Déconstruction de la terminologie : pourquoi chaque SDK contient des API, mais qu'une API n'est pas un SDK

En génie logiciel, les développeurs qui découvrent l'infrastructure de croissance mobile confondent fréquemment une interface de programmation d'applications (API) avec un kit de développement logiciel (SDK). Bien que ces deux concepts fonctionnent ensemble, ils occupent des couches distinctes de l'architecture logicielle.

Une API est strictement une spécification d'interface et un contrat de communication. Elle définit les signatures de méthodes, les structures de données, la syntaxe des URI selon la norme IETF RFC 3986 et les formats de réponse qui permettent à un composant logiciel d'interagir avec un autre. Les API existent à plusieurs niveaux : il peut s'agir d'interfaces locales de systèmes d'exploitation, d'interfaces de bibliothèques en cours de processus ou de points de terminaison web distants sans état régis par la sémantique HTTP de la norme IETF RFC 9110 (GET, POST). Lors de l'appel direct d'une API REST distante, le développeur d'applications doit construire la requête réseau, gérer la sécurité du transport, analyser la charge utile JSON renvoyée et gérer manuellement les conditions de nouvelle tentative (retry).

À l'inverse, un SDK est le kit d'implémentation complet qui encapsule une ou plusieurs API locales ainsi que la logique d'exécution, la documentation et les outils de développement. Lorsqu'un développeur importe un SDK mobile dans un projet Android Studio ou Xcode, il lie directement le code de la bibliothèque préconstruite dans le binaire de son application. Le SDK expose des API programmatiques locales (telles que initialize(), getInstallParam() ou handleDeepLink()) à l'application hôte tout en gérant en interne la planification des threads, les rappels du système d'exploitation et la communication avec le serveur distant.

Contexte d'exécution : points de terminaison serveur à serveur sans état par rapport aux bibliothèques de runtime côté client avec état

La distinction opérationnelle entre l'appel d'une API web distante et l'intégration d'un SDK mobile natif repose sur le contexte d'exécution et l'accès à l'environnement de l'appareil :

• Résidence des processus et packaging: Une API web distante est exposée via une infrastructure côté serveur et appelée sur un réseau ; l'application côté serveur implémente le point de terminaison, tandis que l'application cliente exécute la logique de gestion des requêtes. En revanche, un SDK mobile est compilé dans l'artefact de publication de l'application (tel qu'un Android App Bundle .aab) ou le package d'application installable (.apk sur Android et .ipa sur iOS) et s'exécute dans l'espace mémoire alloué à l'application sur l'appareil de l'utilisateur final.
• Sensibilité au cycle de vie natif: Les points de terminaison REST distants ne répondent que lorsqu'un client envoie une requête HTTP. Un SDK mobile natif enregistre des observateurs auprès du système d'exploitation mobile, ce qui lui permet de détecter quand l'application se lance, passe d'un état de premier plan à un état d'arrière-plan, ou reçoit une intention de routage au niveau du système.
• Persistance locale optionnelle et mise en file d'attente: Selon son implémentation, un SDK mobile peut stocker l'état de configuration ou mettre en file d'attente les événements de conversion dans un stockage local en bac à sable (tel que SharedPreferences ou SQLite sur Android, et UserDefaults ou le stockage de fichiers d'application sur iOS, tout en réservant le Keychain pour les petits identifiants sensibles) afin que la télémétrie puisse être transmise de manière asynchrone lorsque la connectivité réseau est disponible.

Comparaison architecturale : API web distantes et SDK mobiles natifs

Le tableau ci-dessous compare les API web REST sans état distantes aux SDK mobiles natifs compilés selon des dimensions architecturales clés :

Composants principaux d'un kit de développement logiciel mobile

Bibliothèques binaires compilées : Android Archive Bundles et frameworks iOS

Au cœur d'un SDK mobile se trouve une distribution binaire compilée formatée pour la chaîne d'outils de construction du système d'exploitation cible :

• Android Archive (.aar), JAR et App Bundles (.aab): Sur Android, les SDK sont distribués sous forme de packages .aar ou de bibliothèques .jar. Alors qu'un fichier .jar contient du bytecode JVM compilé, un package .aar peut également regrouper des ressources et des entrées de manifeste spécifiques à Android qui fusionnent dans l'application hôte lors des compilations Gradle. Lorsque l'application hôte est compilée pour la version de production, un Android App Bundle (.aab) sert d'artefact de publication plutôt que de package d'application directement installable ; Google Play le traite en APK spécifiques à l'appareil qui sont livrés aux utilisateurs.
• Bibliothèques statiques iOS (.a), frameworks et XCFrameworks: Sur iOS, les SDK sont distribués sous forme de bibliothèques statiques, de packages .framework ou d'archives .xcframework. Une construction .framework standard cible généralement une variante de plateforme spécifique et peut contenir une ou plusieurs architectures de processeur prises en charge, tandis qu'un package Apple XCFramework (.xcframework) est conçu pour regrouper plusieurs variantes de plateforme et d'architecture — telles que des tranches d'appareils iOS ARM64 physiques aux côtés de tranches de simulateur iOS — en un seul artefact distribuable.

Fichiers d'en-tête publics, contrats d'interface et définitions de types

Les binaires compilés nécessitent des contrats de types publics afin que le compilateur de l'application hôte puisse vérifier les appels de méthodes au moment de la compilation :

• Fichiers d'en-tête iOS (.h) et interfaces de pontage: Les SDK iOS basés sur Objective-C fournissent des fichiers d'en-tête publics (tels que OpoInstallSDK.h) déclarant des interfaces de classes, des protocoles de délégués (OpoInstallDelegate) et des modèles de données (OpoinstallData). Dans les projets Swift, ces déclarations sont exposées via un en-tête de pontage Objective-C ou une importation de module.
• Signatures de classes Android et interfaces de rappel: Les SDK Android exposent des classes de points d'entrée publics et des interfaces de rappel génériques (telles que ResultCallBack<OpoData>) dans des espaces de noms de packages documentés.

Manifestes de configuration, AppKeys et déclarations de droits

Un SDK mobile s'appuie sur les métadonnées de configuration de l'hôte pour authentifier les requêtes des locataires (tenants) et enregistrer les hooks de routage du système d'exploitation :

• Identifiant d'application du locataire (AppKey): Déclaré dans la balise <meta-data> du fichier AndroidManifest.xml d'Android ou dans le fichier Info.plist d'iOS (com.opoinstall.APP_KEY), l'AppKey identifie le locataire de l'application lors de l'initialisation du SDK.
• Déclarations de routage du système d'exploitation: Pour prendre en charge le lancement d'applications en un clic, le projet hôte déclare des schémas d'URL personnalisés et des associations de domaines vérifiées (domaines applinks: dans les droits Associated Domains de Xcode et filtres d'intention vérifiés sur Android).

Documentation et projets d'exemple : transformer des bibliothèques compilées en interfaces de développement exploitables

Il est difficile d'adopter une bibliothèque compilée sans spécifications d'intégration claires. Les SDK de qualité production doivent fournir une documentation claire pour les développeurs et, le cas échéant, des projets d'exemple exécutables :

• Documentation pour les développeurs: Définit la compatibilité des versions, l'ordre d'initialisation du cycle de vie, les autorisations requises, les formats de charge utile des rappels et les codes d'erreur afin que les ingénieurs puissent intégrer la bibliothèque de manière prévisible.
• Projets d'exemple et ponts multiplateformes: Des projets de démonstration exécutables minimaux aident les équipes à vérifier le deep linking et la restauration des paramètres. Bien que le centre de téléchargement du SDK mobile distribue principalement les packages SDK natifs Android et iOS de base (actuellement la v2.1.0), les équipes utilisant des frameworks multiplateformes (tels que Flutter ou Unity) font le pont entre ces fonctionnalités SDK natives via des plugins de wrapper ou des canaux de plateforme et doivent vérifier les dépôts de plugins disponibles par rapport à la documentation officielle.

Pourquoi les API web seules ne peuvent pas résoudre l'attribution des installations mobiles

La boîte noire de l'App Store : comment l'isolation du bac à sable brise le suivi traditionnel par cookies web

Dans le développement web standard, le suivi d'un lien de parrainage vers un événement d'inscription repose sur le stockage du navigateur : lorsqu'un visiteur accède à https://example.com/index.html?inviter_id=A102, JavaScript lit la chaîne de requête et stocke inviter_id=A102 dans localStorage ou un cookie HTTP.

Dans l'acquisition d'applications mobiles, cette continuité se rompt à la frontière de l'app store — une barrière structurelle connue sous le nom de boîte noire de l'App Store :

1. Contexte web: Un utilisateur clique sur un lien promotionnel dans un navigateur mobile ou une application sociale, chargeant une page de destination H5 contenant des paramètres personnalisés (?ref=userA&channelCode=ch_01).
2. Passage de relais sur le store: L'application native n'étant pas encore installée, un clic sur le bouton de téléchargement redirige l'utilisateur hors du navigateur vers l'Apple App Store ou le Google Play Store.
3. Isolation du bac à sable: Lorsque l'utilisateur installe et lance l'application native, le système d'exploitation mobile génère le processus dans un système de fichiers et un bac à sable mémoire isolés. L'application native ne peut pas lire les cookies ou le localStorage de la session de navigateur qui a initié le téléchargement.

Combler l'écart entre le web et l'application : le rôle des SDK JS web et des SDK clients natifs

La résolution des paramètres à travers la frontière de l'app store utilise un flux de travail coordonné qui sépare trois concepts connexes — le Deferred Deep Linking (le routage d'un nouvel utilisateur vers un écran cible dans l'application après l'installation), la Restauration des paramètres d'installation (la récupération de paires clé-valeur personnalisées transmises sur le lien H5) et la Correspondance d'attribution (l'association de l'installation à un canal promotionnel spécifique) :

• SDK JS Web pré-installation (script web OpoInstall): Intégré à la page de destination H5, le SDK JS Web analyse les paramètres de requête dynamiques de l'URL de partage (tels que channelCode, shareCode ou les identifiants de salon) et télécharge le contexte de session pré-installation sur le serveur d'attribution avant de déclencher le réveil de l'application ou la redirection vers le store.
• SDK client natif post-installation (SDK Android / iOS): Intégré au binaire de l'application mobile, le SDK natif s'initialise au premier lancement, communique avec les API de la plateforme et le serveur d'attribution, et renvoie les paramètres personnalisés restaurés à l'application cliente via un rappel asynchrone.

[Navigateur Web Mobile : Page de Destination H5]
                 |
                 | 1. Le SDK JS Web analyse les paramètres d'URL (?ref=userA&channelCode=ch01)
                 |    et télécharge le contexte de session pré-installation
                 v
     [Backend du Serveur d'Attribution]
                 |
                 | 2. L'utilisateur télécharge l'application depuis l'App Store / Google Play
                 |    (Les cookies du navigateur ne peuvent pas traverser le bac à sable du SE)
                 v
   [Premier Lancement de l'App Native : SDK Mobile]
                 |
                 | 3. Le SDK Client s'initialise au démarrage et récupère
                 |    les paramètres personnalisés mis en cache + l'ID de canal
                 v
  [Routage In-App & Attribution de Canal]

Mécaniques d'attribution spécifiques à la plateforme : Google Play Install Referrer et réconciliation de contexte iOS

Étant donné qu'Android et iOS maintiennent des architectures d'app store différentes, l'attribution mobile repose sur des mécanismes de plateforme distincts :

• Écosystème Android et API Google Play Install Referrer: Pour les applications distribuées via Google Play, l'intégration native peut utiliser l'officielle API Google Play Install Referrer pour récupérer les métadonnées de parrainage (y compris l'URL du référent et les horodatages de clic/installation) transmises par le Play Store lors de l'installation. Étant donné que l'API Google Play Install Referrer s'applique spécifiquement aux flux d'installation éligibles du Google Play Store, les distributions Android en dehors de Google Play s'en remettent à la correspondance des paramètres H5 côté serveur ou à des packages de canaux Android exportés (fichiers APK contenant des identifiants channelCode intégrés).
• Écosystème iOS et réconciliation de contexte: L'App Store d'Apple ne fournit pas de mécanisme général de transmission de paramètres de requête d'URL équivalent à l'Install Referrer de Google Play. Lorsque l'application est déjà installée, iOS achemine les utilisateurs directement dans l'application via les Universal Links d'Apple, qui vérifient la propriété du domaine via un fichier apple-app-site-association (AASA). Lorsque l'application n'est pas installée, les Universal Links reviennent à un site web et ne garantissent pas de manière indépendante la récupération des paramètres post-installation ; la restauration des paramètres différés nécessite une réconciliation de session côté serveur dès le premier lancement.

Respect des limites de la vie privée des plateformes : directives d'Apple sur la confidentialité des utilisateurs et signaux de correspondance autorisés

Lors de l'évaluation de la manière dont les SDK mobiles rapprochent les visites web pré-installation et les lancements post-installation, les équipes d'ingénierie doivent distinguer les fonctionnalités documentées par les fournisseurs de la conformité aux politiques du système d'exploitation :

• Mécanisme documenté par le fournisseur: La documentation publique du produit OpoInstall décrit un flux de travail d'installation de paramètres et de canal H5 où le SDK Web collecte les caractéristiques de l'empreinte de l'appareil (fingerprint) et les identifiants de canal sur la page H5, et où le SDK Android/iOS natif collecte à nouveau ces caractéristiques lors du premier lancement pour faire correspondre la source d'installation.
• Limite de la politique de la plateforme Apple: En vertu des Directives d'Apple sur la confidentialité des utilisateurs et l'utilisation des données, Apple interdit explicitement de dériver des 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 (fingerprinting). Les applications se livrant à un fingerprinting interdit, ou faisant référence à des SDK tiers qui le font, risquent un rejet lors de l'examen de l'App Store. Par ailleurs, l'autorisation App Tracking Transparency (ATT) est requise lorsque des services tiers de deep linking ou de deferred deep linking transmettent des identifiants uniques ou créent des identités d'utilisateur partagées entre des applications d'entreprises différentes à des fins de ciblage publicitaire, de mesure publicitaire ou de partage avec des courtiers en données. Cependant, le consentement ATT ne rend pas le fingerprinting d'appareil interdit tolérable.
• Exigence d'escalade de conformité et de vérification: Si une version ou une configuration de SDK spécifique repose sur un fingerprinting d'appareil interdit, ni la réalisation d'un audit de données interne général ni l'obtention du consentement de l'utilisateur via l'invite ATT ne rendent ce mécanisme conforme aux directives d'Apple. Si le fournisseur ne peut pas démontrer que le mécanisme de correspondance iOS évite le fingerprinting d'appareil interdit, les développeurs ne doivent pas déployer ce mécanisme d'attribution sur iOS tant qu'une alternative conforme n'a pas été vérifiée de manière indépendante, en suivant les pratiques de gouvernance OWASP Mobile Application Security.
• Calendrier réseau et solutions de repli (fallbacks) non attribuées: Bien qu'iOS n'expose pas d'autorisation générale accordée par l'utilisateur pour l'accès ordinaire à Internet (les développeurs doivent distinguer l'accessibilité générale à Internet de l'autorisation de confidentialité du réseau local d'Apple, qui s'applique à la découverte d'appareils sur le réseau local), l'initialisation du SDK et la récupération des paramètres dépendent toujours de la disponibilité du réseau et du minutage du démarrage. Étant donné que la correspondance différée n'est pas garantie dans toutes les conditions réseau ou en cas de premiers lancements retardés, les applications doivent toujours implémenter des flux de secours harmonieux lorsque les paramètres renvoyés sont vides.

Comment fonctionne un SDK d'attribution mobile tout au long du cycle de vie de l'application

Phase 1 : Gestion des dépendances et liaison au moment de la compilation via Gradle et CocoaPods

Le cycle de vie d'un SDK commence au moment de la compilation lorsque le développeur déclare la dépendance de la bibliothèque via Gradle, CocoaPods ou une importation manuelle d'archives. Pendant la compilation de la construction, le gestionnaire de packages résout l'artefact de la bibliothèque et lie ses symboles binaires dans le package de l'application. Certains SDK mobiles nécessitent des considérations de compatibilité spécifiques pour la réduction du code (code-shrinking) dans les builds de version, et les intégrations de SDK iOS peuvent également nécessiter des déclarations de manifestes de confidentialité spécifiques à la plateforme et des configurations de construction compatibles.

Phase 2 : Initialisation sur le thread principal au démarrage de l'application

Lorsqu'un utilisateur lance l'application, le système d'exploitation mobile crée le processus de l'application et appelle le hook de cycle de vie du point d'entrée principal — Application.onCreate() sur Android tel que détaillé dans le Guide des développeurs Google Android sur le cycle de vie des applications, et application(_:didFinishLaunchingWithOptions:) sur iOS tel que détaillé dans la Documentation du développeur Apple sur UIApplicationDelegate. Un SDK mobile bien conçu doit minimiser le travail pendant le démarrage de l'application et déplacer les opérations réseau vers une exécution asynchrone. Les développeurs doivent vérifier le comportement d'initialisation réel et mesurer les performances de démarrage à froid (cold-start) dans leur build cible.

Phase 3 : Interception des deep links natifs via Universal Links et filtres d'intention

Lorsque l'application est déjà installée et qu'un utilisateur appuie sur un lien H5, le système d'exploitation réveille l'application et transmet le contexte de routage au SDK par le biais de points d'entrée spécifiques à la plateforme :

• Schémas personnalisés Android et App Links vérifiés: Les schémas d'URL personnalisés (scheme://) acheminent via un <intent-filter> BROWSABLE de base. La prise en charge des Android App Links vérifiés nécessite un <intent-filter android:autoVerify="true"> qui déclare à la fois les schémas http et https aux côtés de l'android:host cible, pris en charge par un fichier de liens d'actifs numériques /.well-known/assetlinks.json contenant le nom du package de l'application et l'empreinte du certificat de signature SHA-256.
• Routage iOS AppDelegate et UISceneDelegate: Les Universal Links fournissent un NSUserActivity à AppDelegate dans les applications à cycle de vie traditionnel, ou — pour les applications iOS 13+ adoptant des cycles de vie basés sur des scènes via UISceneDelegate — à scene(_:willConnectTo:options:) au démarrage à froid et à scene(_:continue:) lors de la reprise à chaud.

Phase 4 : Restauration asynchrone des paramètres et mise en file d'attente de la télémétrie des événements

Au premier lancement — ou lorsque des jalons de conversion commerciale se produisent — l'application hôte appelle les méthodes asynchrones du SDK pour récupérer les paramètres d'installation mis en cache (data et channelCode) et signaler les événements de conversion en aval (tels que les inscriptions de comptes ou les points d'effet personnalisés).

Mise en œuvre des hooks de cycle de vie du SDK natif sur Android et iOS

Configuration des identifiants d'application et vérification des versions du SDK

Les modèles d'intégration illustratifs ci-dessous suivent la documentation d'intégration publique d'OpoInstall pour démontrer comment les projets natifs Android et iOS connectent les hooks de cycle de vie décrits ci-dessus. Étant donné que le centre de téléchargement distribue des archives SDK mises à jour (actuellement la v2.1.0, publiée le 2026-09-20) tandis que les exemples de documentation peuvent faire référence à des coordonnées mineures antérieures, les équipes d'ingénierie doivent télécharger le package SDK v2.1.0 cible, vérifier tous les chemins d'importation et signatures de méthodes par rapport aux en-têtes de bibliothèque groupés, et exécuter une vérification de compilation propre dans Android Studio et Xcode avant le déploiement en production. Reportez-vous à la documentation technique d'OpoInstall pour obtenir les instructions d'intégration spécifiques à la version.

Modèle d'initialisation du SDK Android et de récupération des paramètres

Dans AndroidManifest.xml, déclarez les autorisations réseau, l'AppKey du locataire et des blocs <intent-filter> séparés pour le réveil par schéma d'URL personnalisé et les Android App Links vérifiés (en déclarant à la fois les schémas http et https conformément aux exigences de vérification des Android App Links, et en remplaçant links.example.com par votre domaine vérifié) :

<!-- Fichier : app/src/main/AndroidManifest.xml (Modèle d'intégration illustratif) -->
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.example.app">

    <uses-permission android:name="android.permission.INTERNET"/>
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>

    <application
        android:name=".CustomApplication"
        android:allowBackup="true">

        <meta-data
            android:name="com.opoinstall.APP_KEY"
            android:value="OPOINSTALL_APPKEY"/>

        <activity
            android:name=".MainActivity"
            android:exported="true"
            android:launchMode="singleTask">

            <!-- 1. Filtre de réveil par schéma d'URL personnalisé -->
            <intent-filter>
                <action android:name="android.intent.action.VIEW"/>
                <category android:name="android.intent.category.DEFAULT"/>
                <category android:name="android.intent.category.BROWSABLE"/>
                <data android:scheme="OPOINSTALL_SCHEME"/>
            </intent-filter>

            <!-- 2. Filtre Android App Links vérifié (nécessite /.well-known/assetlinks.json avec l'empreinte de certificat SHA-256) -->
            <intent-filter android:autoVerify="true">
                <action android:name="android.intent.action.VIEW"/>
                <category android:name="android.intent.category.DEFAULT"/>
                <category android:name="android.intent.category.BROWSABLE"/>
                <data android:scheme="http"/>
                <data android:scheme="https"/>
                <data android:host="links.example.com"/>
            </intent-filter>
        </activity>
    </application>
</manifest>

// Fichier : app/src/main/java/com/example/app/CustomApplication.java
package com.example.app;

import android.app.Application;
import com.opoinstall.api.OpoInstall;

public class CustomApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        OpoInstall.initialize(this);
    }
}

// Fichier : app/src/main/java/com/example/app/MainActivity.java
// Remarque : Vérifiez les importations de packages exactes et les signatures de rappels par rapport à votre archive SDK v2.1.0 téléchargée.
package com.example.app;

import android.content.Intent;
import android.os.Bundle;
import android.util.Log;
import androidx.appcompat.app.AppCompatActivity;
import com.opoinstall.api.OpoInstall;
import com.opoinstall.api.OpoData;
import com.opoinstall.api.OpoError;
import com.opoinstall.api.ResultCallBack;

public class MainActivity extends AppCompatActivity {
    private static final String TAG = "OpoInstallSDK";

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        OpoInstall.getInstance().start(this);

        // Traiter l'intention de réveil si l'application est lancée via un schéma personnalisé ou un App Link vérifié
        getWakeUpData(getIntent());

        // Récupérer les paramètres d'installation différés lorsque la logique d'onboarding en a besoin
        OpoInstall.getInstance().getInstallParam(new ResultCallBack<OpoData>() {
            @Override
            public void onResult(OpoData opoData) {
                Log.d(TAG, "getInstallParam onResult : " + opoData);
            }

            @Override
            public void onError(OpoError opoError) {
                Log.e(TAG, "getInstallParam onError : " + opoError);
            }
        });
    }

    @Override
    protected void onNewIntent(Intent intent) {
        super.onNewIntent(intent);
        getWakeUpData(intent);
    }

    private void getWakeUpData(Intent intent) {
        OpoInstall.getInstance().handleDeepLink(intent, new ResultCallBack<OpoData>() {
            @Override
            public void onResult(OpoData opoData) {
                Log.d(TAG, "handleDeepLink onResult : " + opoData);
            }

            @@Override
            public void onError(OpoError opoError) {
                Log.d(TAG, "handleDeepLink onError : " + opoError);
            }
        });
    }
}

Modèle d'enregistrement de délégué du SDK iOS et de réveil SceneDelegate

Sur iOS, exposez #import "OpoInstallSDK.h" dans votre en-tête de pontage Objective-C, configurez com.opoinstall.APP_KEY dans Info.plist et implémentez OpoInstallDelegate. Utilisez les méthodes de gestion d'URL de l'AppDelegate pour les applications qui n'adoptent pas la gestion du cycle de vie basée sur les scènes ; pour les applications basées sur des scènes, traitez les Universal Links de démarrage à froid et de reprise à chaud et les schémas d'URL via les méthodes SceneDelegate correspondantes :

// Fichier : AppDelegate.swift & SceneDelegate.swift (Modèle d'intégration illustratif)
// Remarque : Vérifiez les en-têtes de pontage Objective-C exacts et les signatures de méthodes par rapport à votre archive SDK iOS v2.1.0 téléchargée.
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        OpoInstallSDK.initWith(self)
        return true
    }

    // Pour les applications qui n'adoptent PAS la gestion du cycle de vie UISceneDelegate :
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }

    func application(
        _ app: UIApplication,
        open url: URL,
        options: [UIApplication.OpenURLOptionsKey: Any] = [:]
    ) -> Bool {
        OpoInstallSDK.handLinkURL(url)
        return true
    }

    func getWakeUpParams(_ appData: OpoinstallData?) {
        print("Données de réveil : \(String(describing: appData?.data)), code de canal : \(String(describing: appData?.channelCode))")
    }

    func fetchInstallParameters() {
        OpoInstallSDK.defaultManager()?.getInstallParmsCompleted({ (appData: OpoinstallData?) in
            print("Données d'installation : \(String(describing: appData?.data)), code de canal : \(String(describing: appData?.channelCode))")
        })
    }
}

// Pour les applications iOS 13+ qui adoptent la gestion du cycle de vie UISceneDelegate :
@available(iOS 13.0, *)
class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?

    func scene(
        _ scene: UIScene,
        willConnectTo session: UISceneSession,
        options connectionOptions: UIScene.ConnectionOptions
    ) {
        for userActivity in connectionOptions.userActivities {
            OpoInstallSDK.continue(userActivity)
        }
        for urlContext in connectionOptions.urlContexts {
            OpoInstallSDK.handLinkURL(urlContext.url)
        }
    }

    func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
        OpoInstallSDK.continue(userActivity)
    }

    func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
        for urlContext in URLContexts {
            OpoInstallSDK.handLinkURL(urlContext.url)
        }
    }
}

Quand les équipes d'ingénierie doivent-elles intégrer un SDK mobile tiers

Scénarios adaptés à l'intégration d'un SDK mobile spécialisé

L'intégration d'un SDK d'attribution mobile et de deep linking dédié est appropriée dans les conditions suivantes :

• Parcours de parrainage et d'onboarding sans code: Applications gérant des programmes de parrainage ou des invitations à des salons multijoueurs où les paramètres (?ref=userA ou room_id=402) doivent être restaurés après l'installation depuis le store sans saisie de code manuelle.
• Campagnes H5 et codes QR multicanaux: Équipes marketing distribuant des liens sur les réseaux sociaux, des codes QR hors ligne et des packages de canaux Android qui nécessitent un suivi unifié des visites, des clics, des installations et des inscriptions.
• Lancement web-à-application en un clic: Produits qui acheminent les utilisateurs existants de l'application directement depuis les navigateurs mobiles vers des vues spécifiques dans l'application via des Universal Links et des App Links tout en guidant les utilisateurs non équipés vers l'app store approprié.

Scénarios où une API REST directe suffit

À l'inverse, un SDK d'attribution côté client est inutile lorsque le flux de travail ne traverse pas les bacs à sable mobiles natifs :

• Transactions backend authentifiées: Lorsqu'un utilisateur déjà authentifié renouvelle un abonnement ou déclenche un webhook de facturation backend, l'enregistrement de cette conversion via une API REST directe de serveur à serveur (S2S) évite les mises à jour de dépendances côté client.
• Applications web exclusivement sur navigateur: Les applications web progressives (PWA) et les sites web mobiles qui ne distribuent pas de binaires natifs via l'App Store ou Google Play peuvent suivre les parrainages à l'aide de cookies web first-party standard et de paramètres de requête d'URL.

Idées reçues courantes en ingénierie concernant les SDK mobiles

• Idée reçue 1 : L'intégration d'un SDK mobile bloque automatiquement le démarrage à froid de l'application: Un SDK mobile bien conçu minimise le travail lors de Application.onCreate() ou didFinishLaunchingWithOptions: et déplace les opérations réseau vers une exécution asynchrone, bien que les développeurs doivent toujours profiler la latence de démarrage à froid dans leur build cible.
• Idée reçue 2 : Les packages de canaux Android remplacent les identifiants de canal des liens H5: Lorsqu'une application Android utilise à la fois des APK de canaux exportés et des liens de canaux H5, le SDK OpoInstall permet de récupérer conjointement les paramètres personnalisés et les identifiants de canal ; conformément à la documentation produit d'OpoInstall, si une installation provient d'un lien de canal H5 avec un channelCode distinct, l'ID du lien de canal H5 a la priorité sur l'ID du package de canal dans les rapports statistiques.

Résumé et cadre de décision architecturale

Comprendre ce qu'est un SDK et comment il fonctionne au sein des bacs à sable des systèmes d'exploitation mobiles permet aux équipes d'ingénierie de concevoir des architectures d'acquisition d'utilisateurs et de deep-linking fiables. Alors que les API web sans état gèrent la communication avec les serveurs distants, une intégration native côté client est nécessaire lorsqu'une application doit participer à des événements de cycle de vie natifs ou récupérer des signaux d'installation spécifiques à une plateforme, et un SDK mobile regroupe ces fonctionnalités dans une couche d'intégration réutilisable.

Lorsqu'il s'agit de décider comment structurer votre pipeline d'attribution, appliquez ces directives d'ingénierie :

• Déployer un SDK mobile natif : lorsque les parcours utilisateurs passent de pages de destination H5, de partages sociaux ou de codes QR par l'intermédiaire de l'App Store ou de Google Play et nécessitent une restauration automatisée des paramètres ou un routage Universal Link / App Link en un clic.

• Utiliser des API HTTP de serveur à serveur : lors de l'exportation de statistiques de canaux agrégées vers un entrepôt de données interne, ou lors de l'enregistrement d'événements backend qui ne dépendent pas du contexte de lancement côté client.

• Vérifier la compilation des binaires et la conformité à la confidentialité de la plateforme : testez toujours la compilation de l'archive SDK cible (telle que la v2.1.0) dans un projet propre et confirmez auprès du fournisseur que tout mécanisme de correspondance iOS évite le fingerprinting d'appareil interdit avant la mise en production.

Les équipes d'ingénierie évaluant l'infrastructure d'attribution peuvent enregistrer une clé d'application sur la console développeur d'OpoInstall pour tester la restauration des paramètres et le routage des deep links dans un environnement de staging.

Documents associés

• Concepts : Kit de développement logiciel, Interface de programmation d'applications, Deferred Deep Linking, Isolation par bac à sable du système d'exploitation

• Technologies : Android Archive (.aar), iOS XCFramework, Google Play Install Referrer, Apple Universal Links

• Normes : Sémantique HTTP IETF RFC 9110, Syntaxe générique URI IETF RFC 3986, Projet de sécurité des applications mobiles OWASP

• Interfaces de plateforme et d'intégration : Android Application.onCreate, iOS UIApplicationDelegate, UISceneDelegate, NSUserActivity

• Documentation officielle et références :

  • Guide des développeurs Google Android sur le cycle de vie des applications

  • Guide des développeurs Google Android sur les App Links

  • Guide technique de l'API Google Play Install Referrer

  • Documentation du développeur Apple sur UIApplicationDelegate

  • Documentation du développeur Apple sur UISceneDelegate

  • Documentation du développeur Apple sur la prise en charge des Universal Links

  • Documentation du développeur Apple sur la création d'un bundle de framework binaire multiplateforme (XCFramework)

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