Saltar al contenido principal
Un SDK de iOS ligero y controlado desde el servidor para la verificación de identidad, que requiere una configuración mínima. Última versión: 4.9.1.

Repositorio de GitHub

Consulta el código fuente, las versiones y el registro de cambios completo en GitHub

SDK nativo: Este es el enfoque recomendado para apps de iOS. Los SDK nativos ofrecen la mejor experiencia de usuario, una gestión optimizada de la cámara y compatibilidad completa con NFC.


Requisitos

Compatibilidad con versiones de iOS

El consentimiento biométrico requiere la versión nativa 4.10.0 o posterior. Para las personas amparadas por la legislación de Illinois, Texas o Colorado, Didit puede solicitar un consentimiento biométrico explícito antes de la primera captura facial. El SDK de iOS 4.10.0 y las versiones posteriores muestran ese paso. Las versiones anteriores no pueden mostrarlo: sus sesiones funcionan como hasta ahora y la decisión indica que el consentimiento no se recopiló (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Actualiza si verificas a personas en esos estados.

Instalación

Desde la versión 4.0.0, el SDK se distribuye en cuatro variantes instalables, de modo que tu aplicación solo asume el tamaño binario de las funciones que usa. Elige exactamente una variante: un subspec de CocoaPods y un producto de biblioteca de SwiftPM:
  • Core: la huella más pequeña, solo captura manual. Sin OpenSSL.xcframework, sin runtime de CoreNFC y sin runtime de ML.
  • AutoDetection: captura automática de documentos y rostros basada en ML, pero sin lectura del chip NFC.
  • NFC: lectura del chip NFC de pasaportes y eID sin el runtime de ML de captura automática.
  • All: todas las funciones. Es la opción predeterminada cuando instalas DiditSDK sin indicar un subspec o producto.
Lo que cada variante añade al bundle de tu aplicación (Mach-O arm64, medido con 4.9.0): Core ~11.1 MB, NFC ~11.7 MB más ~4 MB de OpenSSL, AutoDetection ~16.0 MB, All ~16.6 MB más OpenSSL. Los modelos de detección se descargan en tiempo de ejecución y se almacenan en caché, por lo que nunca cuentan en el tamaño de descarga de tu aplicación. Desde la versión 4.7.1, las variantes AutoDetection y All ejecutan la inferencia de captura automática en un runtime de ML más ligero, en lugar del runtime de MediaPipe usado hasta 4.6.0. Se trata de una transición, no de una variante opcional: se aplica sin condiciones a cualquiera que use 4.7.1 o una versión posterior, así que no existe una variante independiente con el “motor anterior” que puedas instalar en su lugar. Medido sobre los artefactos publicados: -3.4 MB (-28%) en el payload de descarga comprimido de la App Store y -8.5 MB (-35%) en el binario arm64 incluido en tu aplicación (el framework sin comprimir para dispositivo es unos 12 MB más pequeño). Antes de cada lanzamiento se verifica, fotograma a fotograma y en una matriz de dispositivos físicos, que el comportamiento de detección es idéntico al del motor anterior, y la inferencia de documentos es apreciablemente más rápida.
Revertir el cambio de runtime: como se trata de una transición y no de una variante, revertirlo implica fijar tu dependencia a 4.6.0 (SwiftPM: selecciona la versión 4.6.0 en lugar de “Up to Next Major”; CocoaPods: apunta podspec_url a la etiqueta 4.6.0), no cambiar un flag. Didit supervisa el rendimiento real de este runtime durante un ciclo de versiones tras su lanzamiento; si aparece una regresión, la respuesta será un aviso para fijar la versión anterior más una versión de parche sobre el runtime actual, nunca un cambio de variante, ya que no existe ninguna.
Desde la versión 4.6.0, los frameworks distribuidos ya no incluyen descriptores de ABI de Swift (metadatos de compilación que Xcode copiaba en cada aplicación pero nunca leía) ni videos tutoriales que la variante no puede reproducir. Actualizar desde 4.5.4 o una versión anterior reduce tu aplicación en unos 7-8 MB por sí solo, sin cambios de código. La App Store comprime los binarios para su entrega, por lo que el coste de descarga inalámbrica es menor: consulta el informe de tamaño de la aplicación en App Store Connect para ver la diferencia exacta por dispositivo.
Las variantes NFC y All incluyen OpenSSL.xcframework (OpenSSL 3.3.3, distribuido como OpenSSL-Universal 3.3.3001 a través de NFCPassportReader), que es necesario para la autenticación del chip NFC y requiere iOS 15.0+. Las versiones hasta la 4.0.6 inclusive incluían OpenSSL 1.1.1s; la 4.0.7 y posteriores incluyen OpenSSL 3.3.3 con su propio manifiesto de privacidad y firma de código: instala siempre la 4.0.7 o una posterior. Ten en cuenta que actualizar alinea las versiones de OpenSSL, pero no elimina los conflictos al incrustar: si otra dependencia de tu aplicación también incrusta un OpenSSL.framework (mismo nombre de archivo, mismo bundle id com.github.krzyzanowskim.OpenSSL), las dos copias entran en conflicto en el paso de incrustación sin importar la versión. Conserva exactamente una copia; por ejemplo, anula el otro paquete mediante su identidad de SPM para que use el OpenSSL.xcframework publicado por Didit, de modo que el binario del bundle sea aquel con el que se compiló este SDK. Las variantes Core y AutoDetection no enlazan OpenSSL en absoluto.
import DiditSDK es igual en el código de tu aplicación, sea cual sea la variante que instales.

Swift Package Manager (recomendado)

Añade el paquete a tu proyecto desde Xcode:
  1. Ve a File > Add Package Dependencies
  2. Introduce la URL del repositorio:
  1. Selecciona la versión (o Up to Next Major desde 4.9.1) y haz clic en Add Package
  2. Cuando se te pida elegir un producto, selecciona exactamente un producto de biblioteca para tu variante (consulta la tabla anterior)
O bien en tu Package.swift:
Después, añade exactamente uno de estos productos a tu target:
Swift Package Manager no aplica por ti el mínimo de iOS 15. Package.swift declara platforms: [.iOS(.v13)] para todo el paquete, por lo que Xcode te permitirá añadir DiditSDK o DiditSDKNFC a un target de iOS 13 o 14 sin advertencias, pero ambos incluyen OpenSSL.xcframework y leen chips mediante NFCPassportReader, que requieren iOS 15.0+. Establece tú mismo el deployment target de tu target en 15.0 cuando uses el producto All o NFC. CocoaPods lo aplica automáticamente mediante el deployment_target del subspec.

CocoaPods

DiditSDK se distribuye como un podspec binario alojado en el repositorio (no está en el CocoaPods Trunk público), por lo que debes hacer referencia a la URL del podspec. Elige exactamente un subspec:
Core y AutoDetection son compatibles con iOS 13; NFC y All requieren iOS 15 debido a NFCPassportReader. Después ejecuta:
Después de pod install, abre el .xcworkspace generado (no el .xcodeproj).
Errores de rsync en Xcode 15+: si ves errores de rsync Operation not permitted durante la compilación, establece Build Settings → User Script Sandboxing (ENABLE_USER_SCRIPT_SANDBOXING) en No en el proyecto, tanto para Debug como para Release.

Manual (XCFramework)

Cada versión publica un XCFramework por variante. Descarga los archivos zip de tu variante desde la página de GitHub Releases, arrastra las carpetas .xcframework a Xcode y selecciona Embed & Sign.

Permisos

El SDK requiere los siguientes permisos. Agrégalos al Info.plist de tu aplicación:

Ejemplo de entradas de Info.plist

Configuración de NFC

Solo es necesaria si instalas la variante NFC o All. Omite esta sección si instalaste la variante Core o AutoDetection. Para habilitar la lectura NFC de pasaportes y documentos de identidad con chip:
  1. Agrega la capacidad NFC en Xcode:
    • Selecciona tu target → Signing & Capabilities → + Capability → Near Field Communication Tag Reading
  2. Agrega los identificadores ISO7816 a Info.plist:
D392F000260100000001 permite que el SDK lea la My Number Card de Japón mediante JPKI: sin él, iOS no notifica la tarjeta al SDK. La lectura de la My Number Card aún no está habilitada en producción, y el identificador no cambia nada para los demás documentos, así que puedes agregarlo ya.
  1. Agrega los entitlements (en tu archivo .entitlements):
Limitación del simulador (variantes NFC y All): estas variantes enlazan CoreNFC y, desde Xcode 12, libnfshared.dylib no está disponible en los simuladores. Consulta este hilo de Stack Overflow para ver una solución alternativa. Esto no afecta a la variante Core ni a la AutoDetection. Prueba las funciones NFC solo en dispositivos físicos.

Revisión de App Store (variantes NFC y All): si instalas la variante NFC o All, Apple puede solicitar un video de demostración durante la revisión, porque el código relacionado con NFC forma parte del binario del SDK, aunque tu flujo de verificación no use NFC. Solicita nuestro video de demostración de NFC para enviarlo a Apple escribiendo a support@didit.me. Esto no afecta a la variante Core ni a la AutoDetection.


Inicio rápido

Integración con SwiftUI

Integración con UIKit


Métodos de integración

El SDK admite dos métodos de integración: No requiere backend. El SDK crea la sesión directamente con el ID de tu flujo de la Didit Console. El método UniLink (startVerification(workflowId:)) solo admite vendorData; para cualquier otro parámetro de sesión, usa el método 2.
Para que vendorData se asocie a la sesión mediante UniLink, habilita la opción Datos del Proveedor en la Didit Console.

Método 2: sesión desde el backend (recomendado para producción)

Tu backend crea la sesión mediante la API de creación de sesiones de verificación (POST /v3/session/) con todos los parámetros disponibles (contact_details, expected_details, metadata, callback, etc.) y luego pasa el session_token al SDK.
Este enfoque te da control total sobre:
  • La asociación de las sesiones con tus usuarios (vendor_data)
  • La configuración de los datos de contacto y los datos esperados para la validación cruzada
  • La configuración de metadatos personalizados
  • La configuración de callbacks por sesión Estos datos (datos de contacto, datos esperados, metadatos y callback) se envían a la API de creación de sesiones de verificación.

Configuración

Personaliza el comportamiento del SDK con DiditSdk.Configuration:

Opciones de configuración

Opciones de cámara

Las opciones de cámara coinciden con las opciones de cámara del Web SDK. Cada lente puede ser .front o .back. Si el dispositivo no tiene la lente solicitada, el SDK usa la primera cámara disponible. El selector de cámara también se oculta en los dispositivos que solo tienen una cámara. Establece una opción de selector en false para restringir al usuario a la lente predeterminada de ese paso.
Temas y colores: los colores, los fondos y la configuración de la pantalla de introducción se definen en tu configuración de marca blanca en la consola de Didit, no en la configuración del SDK. Así se garantiza una imagen de marca coherente en todas las plataformas.
Las opciones showLanguageSelector, showCloseButton, showExitConfirmation y closeOnComplete coinciden con la DiditSdkConfiguration del Web SDK. Las opciones específicas de móvil languageLocale y fontFamily existen porque el SDK móvil renderiza de forma nativa toda la interfaz de verificación (a diferencia del Web SDK, que delega en el frontend alojado dentro de un iframe).

Compatibilidad de idiomas

El SDK admite 54 idiomas. Si no se especifica ningún idioma, el SDK usa la configuración regional del dispositivo, con el inglés como alternativa.
Ver todos los idiomas admitidos →

Parámetros avanzados de sesión

Para los parámetros avanzados de sesión (contact_details, expected_details, metadata, callback), usa el método Backend Session. Tu backend invoca la API Create Verification Session con todos los parámetros y después pasa el session_token al SDK.

Gestión de resultados

El enum VerificationResult proporciona el resultado de la verificación:

Casos de resultado

Propiedades de SessionData

Tipos de error

Pérdida de conexión

Si el dispositivo pierde la conexión durante la verificación, el SDK muestra una pantalla de “No internet connection” durante el flujo en lugar de dejar un paso cargando. Sigue comprobando la conexión en segundo plano y cierra la pantalla por sí solo en cuanto se puede volver a conectar con Didit, y el usuario continúa desde el paso en el que estaba. La pantalla ofrece Try Again y, cuando showCloseButton es true (el valor predeterminado), Exit Verification. Al salir, la verificación termina con .failed(error: .networkError, session:), de modo que tu aplicación sabe que el usuario salió debido a la conexión.

Ejemplo completo de gestión de resultados


Cerrar la verificación mediante código

Disponible en DiditSDK 3.6.0+.
La app anfitriona puede finalizar una verificación activa mediante código con DiditSdk.shared.dismiss(). Es la forma recomendada de cerrar la verificación cuando la app anfitriona necesita recuperar el control de la pantalla, por ejemplo, cuando la app pasa a segundo plano.
dismiss() pasa por el flujo de finalización normal del SDK: cierra la interfaz presentada, restablece el estado interno e invoca el handler .diditVerification con .cancelled(session:), que incluye el sessionId actual si se llegó a crear una sesión. No tiene ningún efecto cuando no hay ninguna verificación activa.

Ejemplo: cerrar cuando la app pasa a segundo plano

No asignes DiditSdk.shared.isPresented = false para cerrar la verificación: el indicador solo dispara la presentación en su flanco de subida, y asignarle false no tiene ningún efecto. Del mismo modo, no se admite invocar dismiss(animated:) de UIKit en el view controller superior: omite el flujo de finalización del SDK, por lo que tu handler .diditVerification nunca se ejecuta.

Observar el estado del SDK

Puedes observar el estado del SDK para mostrar una interfaz de carga personalizada:

Ejemplo de extremo a extremo (sesión en el backend → SDK de iOS → resultado)

Este patrón es la integración preparada para producción. Tu backend crea la sesión, tu app de iOS recibe el session_token y el SDK ejecuta el flujo.

1. Backend: crear la sesión

2. iOS: intercambiar el token e iniciar el SDK

3. Backend: recibir la decisión final mediante webhook

El resultado del SDK es útil para proporcionar comentarios en la interfaz, pero el resultado definitivo llega mediante webhook. Consulta la guía de webhooks para la verificación HMAC.

Ejemplo completo con SwiftUI


Última modificación el 1 de noviembre de 2026