SDK móviles y web
Los SDK nativos para iOS, Android, React Native y Flutter meten el flujo dentro de tu aplicación y son la única ruta que admite NFC. Los SDK web lo incrustan en tu frontend.
Existen SDK nativos para iOS, Android, React Native y Flutter; los SDK web incrustan el flujo en tu frontend. Usa un SDK nativo cuando necesites NFC o el mejor comportamiento de cámara: un WebView no te da ninguna de las dos cosas. Los resultados siguen llegando por webhook, no desde el SDK.
#Por qué un SDK y no una redirección
Una redirección alojada es la que menos trabajo da y funciona perfectamente bien para la mayoría de los flujos. Un SDK merece la pena cuando:
- Necesitas NFC. El chip de un pasaporte o un documento de identidad no se puede leer desde una página de navegador. Un SDK nativo es la única ruta. Consulta verificación de chip NFC.
- No quieres que el usuario salga de tu aplicación. Una redirección de ida y vuelta es un punto real de abandono en móvil.
- Quieres el mejor comportamiento de cámara. El acceso nativo a la cámara es más fiable que el de un navegador, sobre todo en dispositivos antiguos.
#Qué hay disponible
| Plataforma | Notas |
|---|---|
| iOS | Se distribuye como XCFramework |
| Android | Se distribuye vía Maven |
| React Native | Envuelve los módulos nativos; admite la New Architecture |
| Flutter | Envuelve los módulos nativos |
| JavaScript / web | Incrusta el flujo alojado en tu frontend web |
| Iframe in-context | Renderiza el flujo dentro de tu página en lugar de redirigir |
- Elige tu plataforma y la página te da el fragmento de código de ese stack.
- Aquí están enlazados los SDK nativos y web, cada uno con su propio inicio rápido.
Los requisitos de versión y los mínimos de plataforma cambian con cada lanzamiento, así que consulta la documentación actual del SDK en lugar de una instantánea de esta página de ayuda; y si trabajas con una versión concreta de un framework (una versión concreta del SDK de Expo, por ejemplo), confirma la compatibilidad con tu contacto de Didit antes de comprometerte con ella en un sprint.
#Un WebView no es un SDK nativo
Envolver el flujo web alojado en un WebView parece darte una experiencia dentro de la aplicación. Te da la apariencia de una:
- Sin NFC. El chip sigue sin poder leerse.
- Los permisos de cámara son más difíciles. El acceso a la cámara de un WebView depende de la configuración de la aplicación anfitriona, y hacerlo mal produce exactamente los informes de "la cámara nunca se abrió" cubiertos en solucionar problemas de prueba de vida y coincidencia facial.
- El idioma es el de la aplicación, no el del usuario. Un WebView informa del idioma de la aplicación anfitriona, así que pasa
languageexplícitamente al crear la sesión. Consulta configurar el idioma de la verificación.
Si te vas a tomar la molestia de un flujo dentro de la aplicación, usa el SDK nativo.
#Los resultados siguen viniendo de los webhooks
Esto pilla a la gente por sorpresa: el SDK le dice a tu aplicación que el usuario terminó el flujo. No es la fuente autorizada de la decisión de verificación.
La decisión se produce en el servidor después de ejecutar las comprobaciones, y te llega por webhook. Nunca concedas acceso basándote solo en el callback de finalización del SDK: una señal del lado del cliente es trivialmente falsificable, y puede que las comprobaciones ni siquiera hayan terminado cuando se dispara.
Tratar "el SDK dijo que terminó" como "el usuario está verificado" es el error más grave posible en una integración móvil. Confirma en tu servidor, desde el webhook o el endpoint de decisión, antes de desbloquear nada.
#¿Una aplicación de consumidor, o la tuya propia?
No existe una aplicación de Didit para consumidores separada a la que una sesión alojada entregue a los usuarios para un paso como el NFC. Si quieres tenerlo todo (NFC y no NFC) dentro de una única experiencia de aplicación, esa aplicación es la tuya, con el SDK incrustado en ella.
#Distribución y conflictos de dependencias
La integración del SDK nativo choca en ocasiones con otras dependencias de una aplicación anfitriona: una biblioteca transitiva compartida, o una subspec que fija una versión que otra cosa también fija. Si te encuentras con uno, es un problema concreto y reproducible que merece la pena reportar con tu manifiesto de dependencias en lugar de buscar un rodeo fijando algo antiguo: el arreglo suele pertenecer al SDK.
#Probar en un dispositivo
Sandbox funciona igual a través de un SDK que en cualquier otro sitio: apunta la aplicación a la clave de una aplicación sandbox y cada comprobación queda simulada y sin facturar. Esa es la forma correcta de ensayar un flujo móvil, porque los comportamientos del SDK que más necesitas probar (avisos de permisos, ciclo de vida de la cámara, pasar a segundo plano en mitad de la captura) son comportamientos del dispositivo que no te cuesta nada ejercitar repetidamente. Consulta probar en sandbox.