# SDK móviles y web

Source: https://help.didit.me/es/integration/mobile-sdks
Updated: 2026-10-12

Los SDK nativos para iOS, Android, React Native y Flutter meten el flujo en tu app y son la única ruta con NFC. Los SDK web lo incrustan en el 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

[Video: La guía completa de integración - Didit Academy](https://www.youtube.com/watch?v=fX03-WEu_EI)

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](https://help.didit.me/es/documents-coverage/nfc-chip-verification).
- **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

[Video: Elige el SDK de Didit adecuado - Didit Academy](https://www.youtube.com/watch?v=qHada8ZY24Q&t=14)

| 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 |

![La página Integrate de la consola de Didit con los enlaces del SDK y la documentación](https://help.didit.me/screenshots/integrate-light.webp)

*Todos los SDK empiezan desde la misma página que la API.*

iOS admite Swift Package Manager y CocoaPods; añade los permisos de cámara y NFC en `Info.plist` cuando haga falta. Android se distribuye por Maven. React Native admite Expo mediante una compilación de desarrollo con módulos nativos, no mediante Expo Go.

Los requisitos de versión y los mínimos de plataforma cambian con cada lanzamiento, así que consulta la [documentación actual del SDK](https://docs.didit.me/integration/native-sdks/overview) 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](https://help.didit.me/es/liveness-biometrics/liveness-and-face-match-issues).
- **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 `language` explícitamente al crear la sesión. Consulta [configurar el idioma de la verificación](https://help.didit.me/es/workflows/verification-languages).

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](https://help.didit.me/es/integration/webhooks-basics). 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.

> **Warning:** 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](https://help.didit.me/es/getting-started/sandbox-and-testing).