Cómo los kits de desarrollo de software impulsan la atribución y el crecimiento móvil

¿Qué es un SDK y cómo funciona? Un kit de desarrollo de software (SDK, por sus siglas en inglés) es una colección de bibliotecas, API, herramientas y documentación diseñada para ayudar a los desarrolladores a crear o ampliar aplicaciones de software. En el desarrollo móvil, un SDK incluye comúnmente bibliotecas compiladas integradas en una aplicación nativa para proporcionar funcionalidad específica de la plataforma, como el enlace profundo y la atribución. Cuando los equipos de ingeniería móvil evalúan cómo fluyen los datos de adquisición de usuarios desde una promoción web hacia una aplicación recién instalada, se encuentran con un límite fundamental en el sistema operativo: las interfaces web remotas no pueden acceder por sí solas a los ciclos de vida de las aplicaciones nativas ni atravesar los entornos aislados (sandboxes) de las tiendas de aplicaciones. OpoInstall, una plataforma de atribución móvil y enlaces profundos, proporciona bibliotecas de cliente nativas y scripts web que se coordinan a través de estos entornos aislados para recuperar los parámetros de las campañas y enrutar a los usuarios hacia las vistas internas de la aplicación deseadas.

Un kit de desarrollo de software (SDK) es una colección preempaquetada de bibliotecas, interfaces de programación de aplicaciones (API), archivos de cabecera, documentación para desarrolladores y código de ejemplo diseñado para un sistema operativo o marco de trabajo específico. A diferencia de una API web remota independiente que define una interfaz de comunicación sin estado a través de HTTP, un SDK móvil se ejecuta directamente dentro del proceso en tiempo de ejecución de la aplicación cliente para gestionar el estado local, las devoluciones de llamada (callbacks) del ciclo de vida del sistema operativo y la telemetría de red asíncrona.

Qué es un SDK y en qué se diferencia de una API web estándar

Deconstrucción de la terminología: Por qué todo SDK contiene API, pero una API no es un SDK

En ingeniería de software, los desarrolladores nuevos en la infraestructura de crecimiento móvil suelen confundir una interfaz de programación de aplicaciones (API) con un kit de desarrollo de software (SDK). Aunque ambos conceptos operan juntos, ocupan capas distintas de la arquitectura de software.

Una API es estrictamente una especificación de interfaz y un contrato de comunicación. Define las firmas de métodos, las estructuras de datos, la sintaxis de URI según IETF RFC 3986 y los formatos de respuesta que permiten que un componente de software interactúe con otro. Las API existen en múltiples niveles: pueden ser interfaces de sistema operativo locales, interfaces de bibliotecas en proceso o endpoints web remotos sin estado gobernados por la semántica HTTP de IETF RFC 9110 (GET, POST). Al llamar directamente a una API REST remota, el desarrollador de la aplicación debe construir la solicitud de red, gestionar la seguridad del transporte, analizar la carga útil JSON devuelta y gestionar las condiciones de reintento manualmente.

Por el contrario, un SDK es el kit de implementación completo que encapsula una o más API locales junto con lógica en tiempo de ejecución, documentación y herramientas para desarrolladores. Cuando un desarrollador importa un SDK móvil en un proyecto de Android Studio o Xcode, vincula el código de la biblioteca precompilada directamente en el archivo binario de su aplicación. El SDK expone API programáticas locales (como initialize(), getInstallParam() o handleDeepLink()) a la aplicación host mientras gestiona internamente la programación de hilos, las devoluciones de llamada del sistema operativo y la comunicación con el servidor remoto.

Contexto de ejecución: Endpoints servidor a servidor sin estado frente a bibliotecas de tiempo de ejecución del lado del cliente con estado

La distinción operativa entre invocar una API web remota y la integración de un SDK móvil nativo se centra en el contexto de ejecución y el acceso al entorno del dispositivo:

• Residencia de procesos y empaquetado: Una API web remota se expone a través de una infraestructura del lado del servidor y se invoca a través de una red; la aplicación del lado del servidor implementa el endpoint, mientras que la aplicación cliente ejecuta la lógica de gestión de solicitudes. Por el contrario, un SDK móvil se compila en el artefacto de publicación de la aplicación (como un Android App Bundle .aab) o paquete de aplicación instalable (.apk en Android y .ipa en iOS) y se ejecuta dentro del espacio de memoria asignado de la aplicación en el dispositivo del usuario final.
• Conciencia del ciclo de vida nativo: Los endpoints REST remotos solo responden cuando un cliente envía una solicitud HTTP. Un SDK móvil nativo registra observadores en el sistema operativo móvil, lo que le permite detectar cuándo se inicia la aplicación, cuándo transita entre estados de primer plano y segundo plano, o cuándo recibe una intención (intent) de enrutamiento a nivel del sistema.
• Persistencia local opcional y puesta en cola: Dependiendo de su implementación, un SDK móvil puede almacenar el estado de configuración o poner en cola eventos de conversión en el almacenamiento aislado local (como SharedPreferences o SQLite en Android, y UserDefaults o el almacenamiento de archivos de la aplicación en iOS, reservando Keychain para credenciales pequeñas y sensibles) para que la telemetría pueda transmitirse de forma asíncrona cuando haya conectividad de red disponible.

Comparación arquitectónica: API web remotas frente a SDK móviles nativos

La tabla siguiente contrasta las API web remotas sin estado con los SDK móviles nativos compilados en dimensiones arquitectónicas clave:

Componentes principales dentro de un kit de desarrollo de software móvil

Bibliotecas binarias compiladas: Paquetes Android Archive y frameworks de iOS

En el núcleo de un SDK móvil se encuentra una distribución binaria compilada formateada para la cadena de herramientas de compilación del sistema operativo de destino:

• Android Archive (.aar), JAR y App Bundles (.aab): En Android, los SDK se distribuyen como paquetes .aar o bibliotecas .jar. Si bien un archivo .jar contiene bytecode de la máquina virtual de Java (JVM) compilado, un paquete .aar también puede empaquetar recursos específicos de Android y entradas de manifiesto que se combinan en la aplicación host durante las compilaciones de Gradle. Cuando la aplicación host se compila para su lanzamiento, un Android App Bundle (.aab) sirve como artefacto de publicación en lugar de un paquete de aplicación directamente instalable; Google Play lo procesa en APK específicos para cada dispositivo que se entregan a los usuarios.
• Bibliotecas estáticas de iOS (.a), frameworks y XCFrameworks: En iOS, los SDK se distribuyen como bibliotecas estáticas, paquetes .framework o archivos .xcframework. Una compilación .framework estándar normalmente apunta a una variante de plataforma específica y puede contener una o más arquitecturas de CPU compatibles, mientras que un paquete Apple XCFramework (.xcframework) está diseñado para empaquetar múltiples variantes de plataforma y arquitectura (como cortes de dispositivos iOS ARM64 físicos junto con cortes del simulador de iOS) en un único artefacto distribuible.

Archivos de cabecera públicos, contratos de interfaz y definiciones de tipos

Los binarios compilados requieren contratos de tipos públicos para que el compilador de la aplicación host pueda verificar las llamadas a métodos en tiempo de compilación:

• Archivos de cabecera de iOS (.h) e interfaces de puente: Los SDK de iOS basados en Objective-C proporcionan archivos de cabecera públicos (como OpoInstallSDK.h) que declaran interfaces de clases, protocolos de delegados (OpoInstallDelegate) y modelos de datos (OpoinstallData). En proyectos de Swift, estas declaraciones se exponen a través de un encabezado de puente de Objective-C (Bridging Header) o la importación de módulos.
Firmas de clases de Android e interfaces de devolución de llamada: Los SDK de Android exponen clases de puntos de entrada públicos e interfaces de devolución de llamada genéricas (como ResultCallBack<OpoData>) dentro de espacios de nombres de paquetes documentados.

Manifiestos de configuración, AppKeys y declaraciones de permisos

Un SDK móvil se basa en los metadatos de configuración del host para autenticar las solicitudes de los inquilinos y registrar los ganchos de enrutamiento del SO:

• Identificador de aplicación del inquilino (AppKey): Declarado dentro de la etiqueta <meta-data> del archivo AndroidManifest.xml de Android o en el archivo Info.plist de iOS (com.opoinstall.APP_KEY), el AppKey identifica al inquilino de la aplicación durante la inicialización del SDK.
• Declaraciones de enrutamiento del SO: Para admitir el lanzamiento de aplicaciones con un solo clic, el proyecto host declara esquemas de URL personalizados y asociaciones de dominios verificados (dominios applinks: en los permisos de dominios asociados de Xcode y filtros de intents verificados en Android).

Documentación y proyectos de ejemplo: Convertir bibliotecas compiladas en interfaces de desarrollador utilizables

Una biblioteca compilada es difícil de adoptar sin especificaciones de integración claras. Los SDK de nivel de producción deben proporcionar documentación clara para desarrolladores y, cuando estén disponibles, proyectos de ejemplo ejecutables:

• Documentación para desarrolladores: Define la compatibilidad de versiones, el orden de inicialización del ciclo de vida, los permisos requeridos, los formatos de carga útil de las devoluciones de llamada y los códigos de error para que los ingenieros puedan integrar la biblioteca de forma predecible.
• Proyectos de ejemplo y puentes multiplataforma: Los proyectos de demostración ejecutables mínimos ayudan a los equipos a verificar el enlace profundo y la restauración de parámetros. Si bien el centro de descargas del SDK móvil distribuye principalmente los paquetes centrales de SDK nativos para Android e iOS (actualmente la v2.1.0), los equipos que utilizan frameworks multiplataforma (como Flutter o Unity) conectan estas capacidades de SDK nativo a través de complementos contenedores (wrapper plugins) o canales de plataforma, y deben verificar los repositorios de complementos disponibles con la documentación oficial.

Por qué las API web por sí solas no pueden resolver la atribución de instalaciones móviles

La caja negra de la tienda de aplicaciones: Cómo el aislamiento de sandboxes rompe el seguimiento tradicional de cookies web

En el desarrollo web estándar, el seguimiento de un enlace de referencia hasta un evento de registro se basa en el almacenamiento del navegador: cuando un usuario visita https://example.com/index.html?inviter_id=A102, JavaScript lee la cadena de consulta y almacena inviter_id=A102 en localStorage o en una cookie HTTP.

En la adquisición de aplicaciones móviles, esta continuidad se rompe en el límite de la tienda de aplicaciones, una barrera estructural conocida como la Caja Negra de la Tienda de Aplicaciones:

1. Contexto Web: Un usuario hace clic en un enlace promocional dentro de un navegador móvil o una aplicación social, cargando una página de aterrizaje H5 que transporta parámetros personalizados (?ref=userA&channelCode=ch_01).
2. Transferencia en el Mercado: Debido a que la aplicación nativa aún no está instalada, hacer clic en el botón de descarga redirige al usuario fuera del navegador y lo lleva a Apple App Store o Google Play Store.
3. Aislamiento de Sandbox: Cuando el usuario instala e inicia la aplicación nativa, el sistema operativo móvil genera el proceso dentro de un sistema de archivos y un entorno aislado (sandbox) de memoria aislados. La aplicación nativa no puede leer las cookies ni el localStorage de la sesión del navegador que inició la descarga.

Salvar la brecha entre la web y la aplicación: El papel de los SDK web de JS y los SDK de cliente nativos

La resolución de parámetros a través del límite de la tienda de aplicaciones utiliza un flujo de trabajo coordinado que separa tres conceptos relacionados: el Enlace Profundo Diferido (enrutar a un nuevo usuario a una pantalla interna de destino de la aplicación después de la instalación), la Restauración de Parámetros de Instalación (recuperar pares clave-valor personalizados pasados en el enlace H5) y la Coincidencia de Atribución (asociar la instalación con un canal promocional específico):

• SDK Web JS Preinstalación (Script Web de OpoInstall): Integrado en la página de aterrizaje H5, el SDK Web JS analiza los parámetros de consulta dinámicos de la URL de compartición (como channelCode, shareCode o identificadores de sala) y carga el contexto de la sesión previa a la instalación en el servidor de atribución antes de activar la reactivación de la app o la redirección a la tienda.
• SDK de Cliente Nativo Postinstalación (SDK de Android / iOS): Integrado en el binario de la aplicación móvil, el SDK nativo se inicializa en el primer inicio, se comunica con las API de la plataforma y el servidor de atribución, y devuelve los parámetros personalizados restaurados a la aplicación cliente a través de una devolución de llamada asíncrona.

[Mobile Web Browser: H5 Landing Page]
                 |
                 | 1. Web JS SDK Parses URL Params (?ref=userA&channelCode=ch01)
                 |    & Uploads Pre-Install Session Context
                 v
     [Attribution Server Backend]
                 |
                 | 2. User Downloads App from App Store / Google Play
                 |    (Browser Cookies Cannot Cross OS Sandbox)
                 v
   [Native App First Launch: Mobile SDK]
                 |
                 | 3. Client SDK Initializes on Startup & Retrieves
                 |    Cached Custom Parameters + Channel ID
                 v
  [In-App Routing & Channel Attribution]

Mecánicas de atribución específicas de la plataforma: Google Play Install Referrer frente a la reconciliación de contexto de iOS

Debido a que Android y iOS mantienen arquitecturas de tiendas de aplicaciones diferentes, la atribución móvil se basa en distintos mecanismos de plataforma:

• Ecosistema Android y la API Google Play Install Referrer: Para las aplicaciones distribuidas a través de Google Play, la integración nativa puede utilizar la API oficial de Google Play Install Referrer para recuperar los metadatos de referencia (incluida la URL del referente y las marcas de tiempo de clic e instalación) pasados por Play Store durante la instalación. Dado que la API de Google Play Install Referrer se aplica específicamente a los flujos de instalación elegibles de Google Play Store, las distribuciones de Android fuera de Google Play dependen de la coincidencia de parámetros H5 del lado del servidor o de paquetes de canales de Android exportados (archivos APK que contienen identificadores channelCode incrustados).
• Ecosistema iOS y reconciliación de contexto: La App Store de Apple no proporciona un mecanismo general de transferencia de parámetros de consulta de URL equivalente al Install Referrer de Google Play. Cuando la aplicación ya está instalada, iOS enruta a los usuarios directamente a la aplicación a través de Apple Universal Links, los cuales verifican la propiedad del dominio mediante un archivo apple-app-site-association (AASA). Cuando la aplicación no está instalada, los Universal Links recurren a un sitio web y no garantizan de forma independiente la recuperación de parámetros posteriores a la instalación; la restauración de parámetros diferidos requiere la reconciliación de la sesión del lado del servidor en el primer inicio.

Respeto de los límites de privacidad de la plataforma: Pautas de privacidad del usuario de Apple y señales de coincidencia permitidas

Al evaluar cómo los SDK móviles reconcilian las visitas web preinstalación con los lanzamientos postinstalación, los equipos de ingeniería deben distinguir las características documentadas por el proveedor del cumplimiento de las políticas del sistema operativo:

• Mecanismo documentado por el proveedor: La documentación pública del producto de OpoInstall describe un flujo de trabajo de instalación de canales y parámetros H5 en el que el SDK Web recopila características de huella digital del dispositivo (fingerprinting) y ID de canales en la página H5, y el SDK nativo de Android/iOS vuelve a recopilar las características del dispositivo en el primer inicio para hacer coincidir la fuente de instalación.
• Límite de la política de la plataforma Apple: Bajo las Pautas de privacidad del usuario y uso de datos de Apple, Apple prohíbe explícitamente derivar datos de un dispositivo (como la combinación de propiedades del navegador, direcciones IP o configuraciones del sistema) con el fin de identificar unívocamente a un usuario o dispositivo (creación de huellas digitales o fingerprinting). Las aplicaciones que participan en la creación de huellas digitales prohibida, o que hacen referencia a SDK de terceros que lo hacen, corren el riesgo de ser rechazadas durante la revisión de la App Store. Por separado, se requiere la autorización de transparencia en el seguimiento de aplicaciones (ATT) cuando los servicios de enlaces profundos o enlaces profundos diferidos de terceros transmiten identificadores únicos o crean identidades de usuario compartidas en aplicaciones de diferentes empresas para la segmentación publicitaria, la medición publicitaria o el intercambio con corredores de datos. Sin embargo, el consentimiento de ATT no hace que la creación de huellas digitales de dispositivos prohibida sea permisible.
• Escalado de cumplimiento y requisito de verificación: Si una versión o configuración específica de un SDK se basa en la creación prohibida de huellas digitales del dispositivo, ni la realización de una auditoría interna general de datos ni la obtención del consentimiento del usuario a través del aviso de ATT hacen que dicho mecanismo cumpla con las pautas de Apple. Si el proveedor no puede demostrar que el mecanismo de coincidencia de iOS evita la creación de huellas digitales del dispositivo prohibida, los desarrolladores no deben implementar ese mecanismo de atribución en iOS hasta que se haya verificado de forma independiente una alternativa compatible, siguiendo las prácticas de gobernanza de OWASP Mobile Application Security.
• Tiempos de red y alternativas no atribuidas (fallbacks): Si bien iOS no expone un permiso general concedido por el usuario para el acceso ordinario a internet (los desarrolladores deben distinguir la accesibilidad general a internet del permiso de privacidad de red local de Apple, que se aplica al descubrimiento de dispositivos en redes locales), la inicialización del SDK y la recuperación de parámetros aún dependen de la disponibilidad de la red y del tiempo de inicio. Como la coincidencia diferida no está garantizada en todas las condiciones de red o en inicios retrasados, las aplicaciones siempre deben implementar flujos de alternativa elegantes cuando los parámetros devueltos estén vacíos.

Cómo funciona un SDK de atribución móvil en el ciclo de vida de la aplicación

Fase 1: Gestión de dependencias y vinculación en tiempo de compilación mediante Gradle y CocoaPods

El ciclo de vida de un SDK comienza en tiempo de compilación cuando el desarrollador declara la dependencia de la biblioteca a través de Gradle, CocoaPods o la importación manual de archivos. Durante la compilación de la compilación, el administrador de paquetes resuelve el artefacto de la biblioteca y vincula sus símbolos binarios en el paquete de la aplicación. Algunos SDK móviles requieren consideraciones de compatibilidad de reducción de código específicas en las compilaciones de lanzamiento, y las integraciones de SDK de iOS también pueden requerir declaraciones de manifiesto de privacidad específicas de la plataforma y configuraciones de compilación compatibles.

Fase 2: Inicialización en el hilo principal al iniciar la aplicación

Cuando un usuario inicia la aplicación, el sistema operativo móvil crea el proceso de la aplicación e invoca el gancho principal del ciclo de vida del punto de entrada: Application.onCreate() en Android, tal como se detalla en la Guía para desarrolladores de Google Android sobre el ciclo de vida de la aplicación, y application(_:didFinishLaunchingWithOptions:) en iOS, tal como se detalla en la Documentación para desarrolladores de Apple sobre UIApplicationDelegate. Un SDK móvil bien diseñado debe minimizar el trabajo durante el inicio de la aplicación y trasladar las operaciones de red a la ejecución asíncrona. Los desarrolladores deben verificar el comportamiento de inicialización real y medir el rendimiento del arranque en frío (cold-start) en su compilación de destino.

Fase 3: Intercepción de enlaces profundos nativos mediante Universal Links y filtros de intenciones

Cuando la aplicación ya está instalada y un usuario toca un enlace H5, el SO activa la aplicación y entrega el contexto de enrutamiento al SDK a través de puntos de entrada específicos de la plataforma:

• Esquemas personalizados de Android frente a App Links verificados: Los esquemas de URL personalizados (scheme://) se enrutan a través de un <intent-filter> BROWSABLE básico. La compatibilidad con Android App Links verificados requiere un <intent-filter android:autoVerify="true"> que declare tanto los esquemas http como https junto con el android:host de destino, respaldado por un archivo de enlaces de activos digitales /.well-known/assetlinks.json que contenga el nombre del paquete de la aplicación y la huella digital del certificado de firma SHA-256.
• Enrutamiento en AppDelegate y UISceneDelegate de iOS: Los Universal Links entregan un NSUserActivity al AppDelegate en las aplicaciones con ciclos de vida tradicionales, o bien (para aplicaciones con iOS 13+ que adoptan ciclos de vida basados en escenas a través de UISceneDelegate) a scene(_:willConnectTo:options:) en el arranque en frío y a scene(_:continue:) en la reanudación en caliente.

Fase 4: Restauración de parámetros asíncronos y puesta en cola de telemetría de eventos

En el primer inicio (o cuando ocurren hitos de conversión de negocio), la aplicación host invoca los métodos asíncronos del SDK para recuperar los parámetros de instalación en caché (data y channelCode) y reportar eventos de conversión posteriores (como registros de cuentas o puntos de efectos personalizados).

Implementación de ganchos del ciclo de vida del SDK nativo en Android e iOS

Configuración de identificadores de aplicaciones y verificación de versiones de SDK

Los patrones de integración ilustrativos a continuación siguen la documentación de integración pública de OpoInstall para demostrar cómo los proyectos nativos de Android e iOS conectan los ganchos del ciclo de vida descritos anteriormente. Debido a que el centro de descargas distribuye archivos SDK actualizados (actualmente la v2.1.0, lanzada el 2026-09-20), mientras que los ejemplos de documentación pueden hacer referencia a coordenadas menores anteriores, los equipos de ingeniería deben descargar el paquete SDK v2.1.0 de destino, verificar todas las rutas de importación y firmas de métodos con los encabezados de las bibliotecas empaquetadas, y ejecutar una verificación de compilación limpia en Android Studio y Xcode antes de la implementación en producción. Consulte la documentación técnica de OpoInstall para obtener instrucciones de integración específicas de la versión.

Patrón de inicialización y recuperación de parámetros del SDK de Android

En AndroidManifest.xml, declare los permisos de red, el AppKey del inquilino y bloques <intent-filter> separados para la activación del esquema de URL personalizado y los Android App Links verificados (declarando los esquemas http y https según los requisitos de verificación de Android App Links, y reemplazando links.example.com con su dominio verificado):

<!-- File: app/src/main/AndroidManifest.xml (Illustrative Integration Pattern) -->
<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. Custom URL Scheme wakeup filter -->
            <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. Verified Android App Links filter (requires /.well-known/assetlinks.json with SHA-256 cert fingerprint) -->
            <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>

// File: 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);
    }
}

// File: app/src/main/java/com/example/app/MainActivity.java
// Note: Verify exact package imports and callback signatures against your downloaded SDK v2.1.0 archive.
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);

        // Process wakeup intent if launched via custom scheme or verified App Link
        getWakeUpData(getIntent());

        // Retrieve deferred installation parameters when needed by onboarding logic
        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);
            }
        });
    }
}

Patrón de registro del delegado del SDK de iOS y reactivación con SceneDelegate

En iOS, exponga #import "OpoInstallSDK.h" en su cabecera de puente (Bridging Header) de Objective-C, configure com.opoinstall.APP_KEY en Info.plist e implemente OpoInstallDelegate. Utilice los métodos de gestión de URL de AppDelegate para las aplicaciones que no adoptan la gestión del ciclo de vida basada en escenas; para las aplicaciones basadas en escenas, procese los Universal Links de arranque en frío y reanudación en caliente, así como los esquemas de URL, a través de los métodos correspondientes de SceneDelegate:

// File: AppDelegate.swift & SceneDelegate.swift (Illustrative Integration Pattern)
// Note: Verify exact Objective-C bridging headers and method signatures against your downloaded iOS SDK v2.1.0 archive.
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

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

    // For apps that do NOT adopt UISceneDelegate lifecycle management:
    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("Wakeup data: \(String(describing: appData?.data)), channelCode: \(String(describing: appData?.channelCode))")
    }

    func fetchInstallParameters() {
        OpoInstallSDK.defaultManager()?.getInstallParmsCompleted({ (appData: OpoinstallData?) in
            print("Install data: \(String(describing: appData?.data)), channelCode: \(String(describing: appData?.channelCode))")
        })
    }
}

// For iOS 13+ apps that adopt UISceneDelegate lifecycle management:
@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)
        }
    }
}

Cuándo deben integrar los equipos de ingeniería un SDK móvil de terceros

Escenarios adecuados para integrar un SDK móvil especializado

La integración de un SDK dedicado de atribución y enlaces profundos es apropiada bajo las siguientes condiciones:

• Flujos de incorporación y referencias sin código: Aplicaciones que ejecutan programas de referidos o invitaciones a salas multijugador en las que los parámetros (?ref=userA o room_id=402) deben restaurarse después de la instalación desde la tienda sin necesidad de introducir códigos manualmente.
• Campañas multicanal H5 y con códigos QR: Equipos de marketing que distribuyen enlaces a través de redes sociales, códigos QR fuera de línea y paquetes de canales de Android que requieren un seguimiento unificado de visitas, clics, instalaciones y registros.
• Lanzamiento web a app con un solo clic: Productos que enrutan a los usuarios existentes de la aplicación directamente desde los navegadores móviles hacia vistas específicas dentro de la app mediante Universal Links y App Links, al tiempo que guían a los usuarios que no la tienen instalada a la tienda de aplicaciones correspondiente.

Escenarios en los que una API REST directa es suficiente

Por el contrario, un SDK de atribución del lado del cliente es innecesario cuando el flujo de trabajo no cruza los entornos aislados (sandboxes) móviles nativos:

• Transacciones autenticadas en el backend: Cuando un usuario ya autenticado renueva una suscripción o activa un webhook de facturación en el backend, registrar dicha conversión mediante una API REST directa de servidor a servidor (S2S) evita actualizaciones de las dependencias del cliente.
• Aplicaciones web exclusivas de navegador: Las aplicaciones web progresivas (PWA) y los sitios web móviles que no distribuyen binarios nativos a través de la App Store o Google Play pueden realizar un seguimiento de las referencias utilizando cookies web de origen estándar y parámetros de consulta de URL.

Conceptos erróneos comunes de ingeniería sobre los SDK móviles

• Concepto erróneo 1: Integrar un SDK móvil bloquea automáticamente el inicio en frío de la aplicación: Un SDK móvil bien diseñado minimiza el trabajo durante Application.onCreate() o didFinishLaunchingWithOptions: y traslada las operaciones de red a una ejecución asíncrona, aunque los desarrolladores siempre deben perfilar la latencia de inicio en frío en su compilación de destino.
• Concepto erróneo 2: Los paquetes de canales de Android anulan los ID de canales de los enlaces H5: Cuando una aplicación de Android utiliza tanto APK de canales exportados como enlaces de canales H5, el SDK de OpoInstall permite recuperar juntos los parámetros personalizados y los ID de canales; según la documentación del producto de OpoInstall, si una instalación se origina a partir de un enlace de canal H5 con un channelCode distintivo, el ID del enlace de canal H5 tiene prioridad sobre el ID del paquete de canales en los informes estadísticos.

Resumen y marco de decisión arquitectónica

Comprender qué es un SDK y cómo funciona dentro de los entornos aislados (sandboxes) del sistema operativo móvil permite a los equipos de ingeniería diseñar arquitecturas confiables de adquisición de usuarios y enlaces profundos. Mientras que las API web sin estado gestionan la comunicación con servidores remotos, se requiere una integración nativa del lado del cliente cuando una aplicación necesita participar en eventos del ciclo de vida nativo o recuperar señales de instalación específicas de la plataforma, y un SDK móvil empaqueta estas capacidades en una capa de integración reutilizable.

Al decidir cómo estructurar su canalización de atribución, aplique estas pautas de ingeniería:

• Desplegar un SDK móvil nativo: Cuando los recorridos de los usuarios transicionan desde páginas de aterrizaje H5, recursos compartidos en redes sociales o códigos QR a través de la App Store o Google Play, y requieren una restauración automatizada de parámetros o enrutamiento con un solo clic mediante Universal Links / App Links.

• Utilizar API HTTP de servidor a servidor: Al exportar estadísticas de canales agregadas a un almacén de datos interno, o al registrar eventos de backend que no dependen del contexto de lanzamiento del lado del cliente.

• Verificar la compilación de binarios y el cumplimiento de la privacidad de la plataforma: Pruebe siempre la compilación del archivo SDK de destino (como la v2.1.0) en un proyecto limpio y confirme con el proveedor que cualquier mecanismo de coincidencia de iOS evite la creación prohibida de huellas digitales del dispositivo antes del lanzamiento a producción.

Los equipos de ingeniería que evalúan la infraestructura de atribución pueden registrar una clave de aplicación en la consola de desarrolladores de OpoInstall para probar la restauración de parámetros y el enrutamiento de enlaces profundos en un entorno de pruebas (staging).

Materiales Relacionados

• Conceptos: Kit de desarrollo de software, Interfaz de programación de aplicaciones, Enlace profundo diferido, Aislamiento de sandbox del SO

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

• Estándares: Semántica HTTP IETF RFC 9110, Sintaxis Genérica URI IETF RFC 3986, Proyecto de Seguridad de Aplicaciones Móviles OWASP

• Interfaces de plataforma e integración: Android Application.onCreate, iOS UIApplicationDelegate, UISceneDelegate, NSUserActivity

• Documentación oficial y referencias:

  • Guía para desarrolladores de Google Android sobre el ciclo de vida de la aplicación

  • Guía para desarrolladores de Google Android sobre App Links

  • Guía técnica de la API Google Play Install Referrer

  • Documentación para desarrolladores de Apple sobre UIApplicationDelegate

  • Documentación para desarrolladores de Apple sobre UISceneDelegate

  • Documentación para desarrolladores de Apple sobre la compatibilidad con Universal Links

  • Documentación para desarrolladores de Apple sobre la creación de un paquete de framework binario multiplataforma (XCFramework)

  • Pautas de privacidad del usuario y uso de datos de Apple