Vai al contenuto principale
Un SDK iOS leggero e guidato dal server per la verifica dell’identità, che richiede una configurazione minima. Ultima versione: 4.13.2.

Repository GitHub

Visualizza il codice sorgente, le release e il changelog completo su GitHub

SDK nativo: Questo è l’approccio consigliato per le app iOS. Gli SDK nativi offrono la migliore esperienza utente, una gestione ottimizzata della fotocamera e pieno supporto NFC.


Requisiti

Compatibilità delle versioni iOS

Il consenso biometrico richiede l’SDK nativo 4.10.0 o successivo. Per le persone soggette alle leggi dell’Illinois, del Texas o del Colorado, Didit può richiedere un consenso biometrico esplicito prima della prima acquisizione del volto. L’SDK iOS 4.10.0 e successivi mostra questo passaggio. Le versioni precedenti non possono mostrarlo: le loro sessioni proseguono come prima e la decisione riporta il consenso come non raccolto (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Aggiorna se verifichi persone in questi stati.

Installazione

A partire dalla versione 4.0.0 l’SDK è distribuito in diverse varianti installabili, così la tua app paga in termini di dimensione del binario solo per le funzionalità che usa. Scegli esattamente una variante: un subspec CocoaPods e un prodotto di libreria SwiftPM.
  • Core — la versione più leggera, con acquisizione automatica di documento e selfie tramite i rilevatori leggeri di Didit. Nessun OpenSSL.xcframework, nessun runtime CoreNFC.
  • AutoDetection — deprecata dalla versione 4.11.0 e identica a Core; usa invece Core.
  • NFC — Core più la lettura del chip di passaporti ed eID tramite NFC.
  • All — tutte le funzionalità. Questa è la variante predefinita quando installi DiditSDK senza indicare un subspec o un prodotto.
Ciò che ogni variante aggiunge al bundle della tua app (Mach-O arm64, misurato sulla versione 4.9.0): Core ~11,1 MB, NFC ~11,7 MB più ~4 MB di OpenSSL, AutoDetection ~16,0 MB, All ~16,6 MB più OpenSSL. I modelli di rilevamento vengono scaricati a runtime e memorizzati nella cache, quindi non incidono mai sulla dimensione del download della tua app. A partire dalla versione 4.11.0 l’acquisizione automatica usa i rilevatori leggeri di Didit in ogni variante. TensorFlow Lite non fa più parte dell’SDK e il framework è più piccolo perché le sue traduzioni vengono caricate dall’esterno del binario. A partire dalla versione 4.6.0 i framework distribuiti non includono più i descrittori ABI di Swift (metadati di build che Xcode copiava in ogni app senza mai leggerli) né i video tutorial che la variante non può riprodurre. Aggiornando dalla 4.5.4 o da una versione precedente, la tua app si riduce di circa 7-8 MB senza bisogno di modifiche al codice. L’App Store comprime i binari per la distribuzione, quindi il costo effettivo del download è inferiore: controlla il report sulla dimensione dell’app in App Store Connect per la differenza esatta per dispositivo.
Le varianti NFC e All includono OpenSSL.xcframework (OpenSSL 3.3.3, distribuito come OpenSSL-Universal 3.3.3001 tramite NFCPassportReader), necessario per l’autenticazione del chip NFC e richiede iOS 15.0+. Le release fino alla 4.0.6 inclusa contenevano OpenSSL 1.1.1s; le 4.0.7 e successive distribuiscono OpenSSL 3.3.3 con il proprio manifesto sulla privacy e la propria firma del codice: installa sempre la 4.0.7 o successiva. Tieni presente che l’aggiornamento allinea le versioni di OpenSSL ma non elimina i conflitti di embed: se un’altra dipendenza della tua app incorpora anch’essa un OpenSSL.framework (stesso nome file, stesso bundle id com.github.krzyzanowskim.OpenSSL), le due copie entrano in conflitto durante la fase di embed, indipendentemente dalla versione. Mantieni una sola copia: ad esempio, sostituisci l’altro package in base all’identità SPM per usare il OpenSSL.xcframework pubblicato da Didit, così il binario nel bundle è quello con cui questo SDK è stato compilato. Le varianti Core e AutoDetection non collegano alcuna libreria OpenSSL.
import DiditSDK è identico nel codice della tua app, indipendentemente dalla variante installata.

Swift Package Manager (consigliato)

Aggiungi il pacchetto al tuo progetto con Xcode:
  1. Vai su File > Add Package Dependencies
  2. Inserisci l’URL del repository:
  1. Seleziona la versione (oppure Up to Next Major a partire da 4.13.2) e fai clic su Add Package
  2. Quando ti viene chiesto di scegliere un prodotto, seleziona esattamente un prodotto di libreria per la tua variante (vedi la tabella sopra)
Oppure nel tuo Package.swift:
Poi aggiungi esattamente uno di questi prodotti al tuo target:
Swift Package Manager non applica da solo il requisito minimo di iOS 15. Package.swift dichiara platforms: [.iOS(.v13)] per l’intero package, quindi Xcode ti permetterà di aggiungere DiditSDK o DiditSDKNFC a un target iOS 13 o 14 senza segnalare errori. Tuttavia entrambi includono OpenSSL.xcframework e leggono i chip tramite NFCPassportReader, che richiedono iOS 15.0+. Imposta manualmente il deployment target del tuo target su 15.0 quando usi il prodotto All o NFC. CocoaPods lo impone automaticamente tramite il deployment_target del subspec.

CocoaPods

DiditSDK è distribuito come podspec binario ospitato nel repository (non è presente sul CocoaPods Trunk pubblico), quindi devi indicare l’URL del podspec. Scegli esattamente un subspec:
Core e AutoDetection supportano iOS 13; NFC e All richiedono iOS 15 a causa di NFCPassportReader. Poi esegui:
Dopo pod install, apri il file .xcworkspace generato (non .xcodeproj).
Errori rsync con Xcode 15+: se durante la build compaiono errori rsync Operation not permitted, imposta Build Settings → User Script Sandboxing (ENABLE_USER_SCRIPT_SANDBOXING) su No nel progetto, sia per Debug sia per Release.

Manuale (XCFramework)

Ogni release pubblica un XCFramework per variante. Scarica gli zip della tua variante dalla pagina GitHub Releases, poi trascina le cartelle .xcframework in Xcode e imposta Embed & Sign.

Autorizzazioni

L’SDK richiede le seguenti autorizzazioni. Aggiungile al file Info.plist della tua app:

Esempi di voci Info.plist

Configurazione NFC

Richiesta solo se installi la variante NFC o All. Salta questa sezione se hai installato la variante Core o AutoDetection. Per abilitare la lettura NFC di passaporti e carte d’identità con chip:
  1. Aggiungi la capability NFC in Xcode:
    • Seleziona il tuo target → Signing & Capabilities → + Capability → Near Field Communication Tag Reading
  2. Aggiungi gli identificatori ISO7816 a Info.plist:
D392F000260100000001 permette all’SDK di leggere la My Number Card giapponese tramite JPKI: senza di esso, iOS non segnala la carta all’SDK. La lettura della My Number Card non è ancora abilitata in produzione e l’identificatore non modifica nulla per gli altri documenti, quindi puoi aggiungerlo già ora.
  1. Aggiungi gli entitlement (nel tuo file .entitlements):
Limitazione del simulatore (varianti NFC e All): Queste varianti collegano CoreNFC e, da Xcode 12, la libreria libnfshared.dylib manca nei simulatori. Per una soluzione alternativa, consulta questo thread di Stack Overflow. Questo non vale per le varianti Core o AutoDetection. Testa le funzionalità NFC solo su dispositivi fisici.

Revisione su App Store (varianti NFC e All): Se installi la variante NFC o All, Apple può chiedere un video dimostrativo durante la revisione, perché il codice relativo a NFC fa parte del binario dell’SDK, anche se il tuo workflow non usa NFC. Richiedi il nostro video dimostrativo NFC da inviare ad Apple a support@didit.me. Questo non vale per le varianti Core o AutoDetection.


Avvio rapido

Integrazione con SwiftUI

Integrazione con UIKit


Metodi di integrazione

L’SDK supporta due metodi di integrazione: Non richiede un backend. L’SDK crea la sessione direttamente usando l’ID del tuo workflow dalla Didit Console. Il metodo UniLink (startVerification(workflowId:)) supporta solo vendorData; per qualsiasi altro parametro di sessione usa il Metodo 2.
Perché vendorData venga associato alla sessione tramite UniLink, abilita l’opzione Dati Fornitore nella Didit Console.

Metodo 2: sessione lato backend (consigliato per la produzione)

Il tuo backend crea la sessione tramite l’API di creazione della sessione di verifica (POST /v3/session/) con supporto completo dei parametri (contact_details, expected_details, metadata, callback e altri), poi passa il session_token all’SDK.
Questo approccio ti offre il pieno controllo su:
  • Associare le sessioni ai tuoi utenti (vendor_data)
  • Impostare i dettagli di contatto e i dettagli attesi per la convalida incrociata
  • Impostare metadati personalizzati
  • Configurare i callback per sessione Questi dati (dettagli di contatto, dettagli attesi, metadati, callback) vengono inviati all’API di creazione della sessione di verifica.

Configurazione

Personalizza il comportamento dell’SDK con DiditSdk.Configuration:

Opzioni di configurazione

Opzioni della fotocamera

Le opzioni della fotocamera corrispondono alle opzioni della fotocamera dell’SDK Web. Ogni obiettivo è .front o .back. Se il dispositivo non dispone dell’obiettivo richiesto, l’SDK utilizza la prima fotocamera disponibile. Il selettore della fotocamera è inoltre nascosto sui dispositivi che hanno una sola fotocamera. Imposta un’opzione del selettore su false per bloccare l’utente sull’obiettivo predefinito di quel passaggio.
Tema e colori: i colori, gli sfondi e le impostazioni della schermata introduttiva si configurano tramite le tue impostazioni White label nella Didit Console, non nella configurazione dell’SDK. Questo garantisce un’identità del marchio coerente su tutte le piattaforme.
Le opzioni showLanguageSelector, showCloseButton, showExitConfirmation e closeOnComplete corrispondono a DiditSdkConfiguration dell’SDK Web. Le opzioni specifiche per dispositivi mobili languageLocale e fontFamily esistono perché l’SDK mobile visualizza l’intera interfaccia di verifica in modo nativo (a differenza dell’SDK Web, che delega al frontend ospitato all’interno di un iframe).

Supporto linguistico

L’SDK supporta 54 lingue. Se non viene specificata alcuna lingua, l’SDK utilizza la lingua del dispositivo, con l’inglese come lingua di ripiego.
Visualizza tutte le lingue supportate →

Parametri avanzati della sessione

Per i parametri avanzati della sessione (contact_details, expected_details, metadata, callback), usa il metodo Backend Session. Il tuo backend chiama la API Create Verification Session con tutti i parametri, quindi passa il session_token all’SDK.

Gestione dei risultati

L’enum VerificationResult fornisce l’esito della verifica:

Casi del risultato

Proprietà di SessionData

Tipi di errore

Connessione persa

Se il dispositivo perde la connessione durante la verifica, l’SDK mostra una schermata “Nessuna connessione Internet” al posto di lasciare un passaggio in caricamento. Continua a controllare in background e chiude la schermata da sola non appena Didit torna raggiungibile, e l’utente prosegue dal passaggio in cui si trovava. La schermata offre Riprova e, quando showCloseButton è true (predefinito), Esci dalla verifica. Uscire termina la verifica con .failed(error: .networkError, session:), così la tua app sa che l’utente è uscito a causa della connessione.

Esempio completo di gestione dei risultati


Chiusura della verifica in modo programmatico

Disponibile in DiditSDK 3.6.0+.
L’app host può terminare una verifica attiva in modo programmatico con DiditSdk.shared.dismiss(). Questo è il modo consigliato per chiudere la verifica quando l’app host deve prendere il controllo dello schermo, ad esempio quando l’app passa in background.
dismiss() passa attraverso la normale pipeline di completamento dell’SDK: chiude l’interfaccia presentata, reimposta lo stato interno e richiama il gestore .diditVerification con .cancelled(session:), che contiene il sessionId corrente se è stata creata una sessione. Se non è attiva alcuna verifica, non ha alcun effetto.

Esempio: chiusura quando l’app passa in background

Non impostare DiditSdk.shared.isPresented = false per chiudere la verifica: il flag attiva la presentazione solo sul fronte di salita, quindi impostarlo a false non ha alcun effetto. Allo stesso modo, chiamare dismiss(animated:) di UIKit sul controller di vista più in alto non è supportato: aggira la pipeline di completamento dell’SDK e il gestore .diditVerification non viene mai eseguito.

Osservazione dello stato dell’SDK

Puoi osservare lo stato dell’SDK per creare un’interfaccia di caricamento personalizzata:

Esempio end-to-end (sessione backend → SDK iOS → risultato)

Questo schema è l’integrazione pronta per la produzione. Il backend crea la sessione, l’app iOS riceve il session_token e l’SDK esegue il flusso.

1. Backend: creare la sessione

2. iOS: scambiare il token e avviare l’SDK

3. Backend: ricevere la decisione finale tramite webhook

Il risultato dell’SDK è comodo per il feedback nell’interfaccia, ma l’esito definitivo arriva tramite webhook. Consulta la guida ai webhook per la verifica HMAC.

Esempio SwiftUI completo


Ultima modifica il 7 novembre 2026