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ón4.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
DiditSDKsin indicar un subspec o producto.
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.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:- Ve a File > Add Package Dependencies
- Introduce la URL del repositorio:
- Selecciona la versión (o Up to Next Major desde
4.9.1) y haz clic en Add Package - Cuando se te pida elegir un producto, selecciona exactamente un producto de biblioteca para tu variante (consulta la tabla anterior)
Package.swift:
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 alInfo.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:-
Agrega la capacidad NFC en Xcode:
- Selecciona tu target → Signing & Capabilities → + Capability → Near Field Communication Tag Reading
-
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.
- Agrega los entitlements (en tu archivo
.entitlements):
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:Método 1: UniLink (el más sencillo)
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.
- 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 conDiditSdk.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.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 enumVerificationResult 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, cuandoshowCloseButton 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+.
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
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 elsession_token y el SDK ejecuta el flujo.