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 versione4.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
DiditSDKsenza indicare un subspec o un prodotto.
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:- Vai su File > Add Package Dependencies
- Inserisci l’URL del repository:
- Seleziona la versione (oppure Up to Next Major a partire da
4.13.2) e fai clic su Add Package - Quando ti viene chiesto di scegliere un prodotto, seleziona esattamente un prodotto di libreria per la tua variante (vedi la tabella sopra)
Package.swift:
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 fileInfo.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:-
Aggiungi la capability NFC in Xcode:
- Seleziona il tuo target → Signing & Capabilities → + Capability → Near Field Communication Tag Reading
-
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.
- Aggiungi gli entitlement (nel tuo file
.entitlements):
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:Metodo 1: UniLink (il più semplice)
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.
- 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 conDiditSdk.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.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’enumVerificationResult 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, quandoshowCloseButton è 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+.
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
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 ilsession_token e l’SDK esegue il flusso.