Integraciones y SDKs

La integración de un servicio externo depende del SDK o del servicio concreto y requiere una evaluación técnica previa. Esta página describe las vías posibles, qué implica cada una y qué información hace falta para evaluarlas.

Las tres vías de integración

Vía web. El proveedor funciona con un script en tu tienda. Las integraciones basadas en web pueden seguir funcionando dentro de la WebView cuando son compatibles con ese entorno, sin necesidad de modificar el binario. Es la vía habitual para analítica y personalización de contenido.

Vía API. La integración ocurre entre servidores: tu sistema habla con el del proveedor, o con la API de push, que es la API pública de Reskyt disponible actualmente. No afecta a la app.

Vía SDK nativo. El proveedor publica una librería para iOS y Android que se compila dentro del binario. Es necesaria cuando la funcionalidad requiere acceso al sistema operativo: notificaciones gestionadas por el proveedor, atribución de instalaciones, biometría, cámara, o un flujo de pago nativo.

La primera cuestión ante cualquier petición de integración es cuál de las tres vías requiere. Cuando se necesitan capacidades específicamente nativas, puede ser necesaria una integración mediante SDK o desarrollo nativo; en el resto de casos, la vía web o la vía API suelen ser suficientes y no requieren ciclo de release.

Cuándo hay que modificar la app

Siempre que la integración sea por SDK nativo. Eso implica recompilar, enviar a revisión en ambas stores y esperar a que los usuarios actualicen. Hasta entonces, el SDK no está en los dispositivos.

La consecuencia de planificación: conviene agrupar varios SDK en una misma release en lugar de hacer una publicación por proveedor.

Impacto en iOS y Android

Un SDK puede no existir para las dos plataformas, o comportarse distinto en cada una. Antes de comprometer una integración hay que confirmar que el proveedor publica librería para ambas y qué versiones mínimas de sistema operativo exige, porque eso puede forzar a subir el mínimo soportado por la app.

Permisos y privacidad

Un SDK puede pedir permisos del sistema (notificaciones, cámara, seguimiento) y recoger datos. Ambas cosas tienen consecuencias fuera del código:

La declaración de privacidad de App Store Connect y Play Console debe reflejar lo que recoge el SDK, y se actualiza en la misma release.

Si el SDK hace seguimiento publicitario, entra además en el terreno del consentimiento del usuario, que se resuelve durante la configuración del proyecto.

Qué necesitamos para evaluar un SDK

1. Nombre del proveedor y enlace a su documentación técnica para iOS y Android.
2. Versiones mínimas de sistema operativo que exige.
3. Permisos del sistema que solicita.
4. Datos que recoge y a dónde los envía.
5. Si necesita puente con la WebView o funciona de forma autónoma.
6. Si el proveedor ofrece soporte de integración y en qué condiciones.
7. Credenciales o entorno de pruebas para validar.

Con eso se puede decir si la integración es viable, por qué vía, y qué implica.

El plazo y las condiciones de la integración se concretan al cerrar la evaluación.

Pruebas y validación

La integración se da por completada cuando se verifica que el proveedor recibe los datos esperados. Esa verificación requiere acceso a su panel durante la validación, que conviene solicitar al inicio del proceso.

Limitaciones a considerar

Ningún SDK es compatible automáticamente. Puede no tener librería para una de las dos plataformas, entrar en conflicto con otro módulo ya activo, exigir una versión de sistema operativo superior a la soportada, o requerir un puente con la WebView que no está resuelto.

Cada uno de esos factores afecta al alcance y al plazo de la integración, y es lo que determina la evaluación técnica previa.