Dépôt GitHub
Consultez le code source, les versions et le journal des modifications complet sur GitHub
SDK natif: Il s’agit de l’approche recommandée pour les applications iOS. Les SDK natifs offrent la meilleure expérience utilisateur, une gestion optimisée de la caméra et la prise en charge complète du NFC.
Prérequis
Compatibilité des versions d’iOS
Le consentement biométrique nécessite la version 4.10.0 ou ultérieure du SDK natif. Pour les personnes couvertes par les lois de l’Illinois, du Texas ou du Colorado, Didit peut demander un consentement biométrique explicite avant la première capture faciale. Le SDK iOS 4.10.0 et les versions ultérieures affichent cette étape. Les versions antérieures ne peuvent pas afficher cette étape : leurs sessions se déroulent comme auparavant, et la décision indique que le consentement n’a pas été recueilli (
biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Mettez à jour si vous vérifiez des personnes dans ces États.Installation
Depuis la version4.0.0, le SDK est livré en plusieurs variantes installables. Votre application n’embarque ainsi que le poids binaire des fonctionnalités qu’elle utilise. Choisissez exactement une variante : une sous-spécification CocoaPods et un produit de bibliothèque SwiftPM.
- Core : la variante la plus légère, avec capture automatique du document et du selfie grâce aux détecteurs légers propres à Didit. Pas de
OpenSSL.xcframework, pas de runtime CoreNFC. - AutoDetection : obsolète depuis la version 4.11.0 et identique à Core ; utilisez plutôt Core.
- NFC : Core plus la lecture des puces des passeports et des cartes d’identité électroniques (eID) en NFC.
- All : toutes les fonctionnalités. C’est la variante par défaut lorsque vous installez
DiditSDKsans nommer de sous-spécification ni de produit.
4.9.0) : Core environ 11,1 MB, NFC environ 11,7 MB plus environ 4 MB d’OpenSSL, AutoDetection environ 16,0 MB, All environ 16,6 MB plus OpenSSL.
Les modèles de détection sont eux-mêmes téléchargés à l’exécution puis mis en cache. Ils ne comptent donc jamais dans la taille de téléchargement de votre application.
Depuis la version 4.11.0, la capture automatique repose sur les détecteurs légers propres à Didit, dans toutes les variantes. TensorFlow Lite ne fait plus partie du SDK. Le framework est plus petit, car ses traductions sont chargées depuis l’extérieur du binaire.
Depuis la version 4.6.0, les frameworks livrés ne contiennent plus les descripteurs ABI Swift (métadonnées de build que Xcode copiait dans chaque application sans jamais les lire) ni les vidéos didactiques que la variante ne peut pas lire. La mise à niveau depuis la version 4.5.4 ou antérieure réduit donc votre application d’environ 7-8 MB à elle seule, sans modification de code.
L’App Store compresse les binaires pour la livraison, de sorte que le coût réel au téléchargement est plus faible. Consultez le rapport de taille d’application dans App Store Connect pour connaître l’écart exact par appareil.
Les variantes NFC et All embarquent
OpenSSL.xcframework (OpenSSL 3.3.3, livré sous la forme OpenSSL-Universal 3.3.3001 via NFCPassportReader), nécessaire à l’authentification des puces NFC, et elles exigent iOS 15.0+. Les versions jusqu’à la 4.0.6 incluse embarquaient OpenSSL 1.1.1s ; les versions 4.0.7 et ultérieures livrent OpenSSL 3.3.3 avec son propre manifeste de confidentialité et sa propre signature de code. Installez toujours la version 4.0.7 ou ultérieure. Notez que la mise à niveau aligne les versions d’OpenSSL, mais ne supprime pas les conflits d’embarquement : si une autre dépendance de votre application embarque aussi un OpenSSL.framework (même nom de fichier, même identifiant de bundle com.github.krzyzanowskim.OpenSSL), les deux copies entrent en conflit lors de l’étape d’embarquement, quelle que soit leur version. Ne gardez qu’une seule copie. Par exemple, remplacez l’autre paquet en utilisant son identité SPM pour utiliser le OpenSSL.xcframework publié par Didit, afin que le binaire présent dans le bundle soit celui avec lequel ce SDK a été compilé. Les variantes Core et AutoDetection n’associent aucune bibliothèque OpenSSL.import DiditSDK reste identique dans le code de votre application, quelle que soit la variante installée.
Swift Package Manager (recommandé)
Ajoutez le paquet à votre projet avec Xcode :- Allez dans File > Add Package Dependencies
- Saisissez l’URL du dépôt :
- Sélectionnez la version (ou Up to Next Major à partir de
4.13.2), puis cliquez sur Add Package - Lorsqu’on vous demande de choisir un produit, sélectionnez exactement un produit de bibliothèque correspondant à votre variante (voir le tableau ci-dessus)
Package.swift :
CocoaPods
DiditSDK est distribué sous forme de podspec binaire hébergé dans le dépôt (il ne figure pas sur le CocoaPods Trunk public). Vous devez donc indiquer l’URL du podspec. Choisissez exactement une sous-spécification :
Core et AutoDetection fonctionnent à partir d’iOS 13. NFC et All exigent iOS 15 à cause de NFCPassportReader.
Exécutez ensuite :
Après
pod install, ouvrez le fichier .xcworkspace généré (et non le .xcodeproj).Erreurs rsync avec Xcode 15+ : si vous voyez des erreurs rsync
Operation not permitted pendant le build, réglez Build Settings → User Script Sandboxing (ENABLE_USER_SCRIPT_SANDBOXING) sur Non pour le projet, en Debug comme en Release.Manuel (XCFramework)
Chaque version publie un XCFramework par variante. Téléchargez les archives zip de votre variante depuis la page GitHub Releases, faites glisser les dossiers.xcframework dans Xcode, puis réglez Embed & Sign.
Autorisations
Le SDK nécessite les autorisations suivantes. Ajoutez-les au fichierInfo.plist de votre application :
Exemples d’entrées Info.plist
Configuration NFC
Obligatoire uniquement lors de l’installation de la variante NFC ou All. Ignorez cette section si vous avez installé la variante Core ou AutoDetection. Pour activer la lecture NFC des passeports et cartes d’identité à puce :-
Ajoutez la capacité NFC dans Xcode :
- Sélectionnez votre cible → Signing & Capabilities → + Capability → Near Field Communication Tag Reading
-
Ajoutez les identifiants ISO7816 à
Info.plist:
D392F000260100000001 permet au SDK de lire la Japan My Number Card via JPKI : sans lui, iOS ne transmet pas la carte au SDK. La lecture de la My Number Card n’est pas encore activée en production, et cet identifiant ne change rien pour les autres documents : vous pouvez donc l’ajouter dès maintenant.
- Ajoutez les droits (dans votre fichier
.entitlements) :
Examen App Store (variantes NFC et All) : Si vous installez la variante NFC ou All, Apple peut demander une vidéo de démonstration pendant l’examen, car du code lié à la NFC fait partie du binaire du SDK, même si votre workflow n’utilise pas la NFC. Demandez notre vidéo de démonstration NFC à l’adresse support@didit.me pour la soumettre à Apple. Cela ne s’applique pas à la variante Core ou AutoDetection.
Démarrage rapide
Intégration SwiftUI
Intégration UIKit
Méthodes d’intégration
Le SDK prend en charge deux méthodes d’intégration :Méthode 1 : UniLink (la plus simple)
Aucun backend requis. Le SDK crée la session directement à partir de l’identifiant de votre workflow dans la Didit Console. La méthode UniLink (startVerification(workflowId:)) ne prend en charge que vendorData : pour tout autre paramètre de session, utilisez la méthode 2.
Pour que
vendorData soit associé à la session via UniLink, activez l’option Données du vendeur dans la Didit Console.Méthode 2 : session backend (recommandée pour la production)
Votre backend crée la session via l’API de création de session de vérification (POST /v3/session/), qui prend en charge l’ensemble des paramètres (contact_details, expected_details, metadata, callback, etc.), puis transmet le session_token au SDK.
- L’association des sessions à vos utilisateurs (
vendor_data) - La définition des coordonnées et des informations attendues pour la validation croisée
- La définition de métadonnées personnalisées
- La configuration des callbacks par session
Configuration
Personnalisez le comportement du SDK avecDiditSdk.Configuration :
Options de configuration
Options de caméra
Les options de caméra correspondent aux options de caméra du SDK Web. Chaque objectif est.front ou .back.
Si l’appareil ne dispose pas de l’objectif demandé, le SDK utilise la première caméra disponible.
Le sélecteur de caméra est également masqué sur les appareils qui n’ont qu’une seule caméra.
Définissez une option de sélecteur sur false pour verrouiller l’utilisateur sur l’objectif par défaut de cette étape.
Thème et couleurs : les couleurs, les arrière-plans et les paramètres de l’écran d’introduction se configurent dans vos paramètres de marque blanche dans la Didit Console, et non dans la configuration du SDK. Cela garantit une identité visuelle cohérente sur toutes les plateformes.
Les options
showLanguageSelector, showCloseButton, showExitConfirmation et closeOnComplete correspondent à DiditSdkConfiguration du SDK Web. Les options propres au mobile languageLocale et fontFamily existent parce que le SDK mobile affiche l’intégralité de l’interface de vérification de manière native (contrairement au SDK Web, qui délègue l’interface frontend hébergée dans un iframe).Langues prises en charge
Le SDK prend en charge 54 langues. Si aucune langue n’est spécifiée, le SDK utilise les paramètres régionaux de l’appareil, avec l’anglais en repli.Paramètres de session avancés
Pour les paramètres de session avancés (contact_details, expected_details, metadata, callback), utilisez la méthode Session backend. Votre backend appelle l’API de création de session de vérification avec l’ensemble des paramètres, puis transmet le session_token au SDK.
Gestion des résultats
L’énumérationVerificationResult fournit le résultat de la vérification :
Cas de résultat
Propriétés de SessionData
Types d’erreurs
Connexion perdue
Si l’appareil perd sa connexion pendant la vérification, le SDK affiche par-dessus le flux un écran « Aucune connexion Internet » au lieu de laisser une étape en cours de chargement. Il continue de vérifier la connexion en arrière-plan et ferme l’écran dès que Didit redevient joignable. L’utilisateur reprend alors à l’étape où il se trouvait. L’écran propose Réessayer et, lorsqueshowCloseButton est true (valeur par défaut), Quitter la vérification.
Quitter met fin à la vérification avec .failed(error: .networkError, session:), afin que votre application sache que l’utilisateur est parti à cause de la connexion.
Exemple complet de gestion des résultats
Fermer programmatiquement la vérification
Disponible dans DiditSDK 3.6.0+.
DiditSdk.shared.dismiss(). C’est la méthode recommandée pour arrêter la vérification lorsque l’application doit reprendre le contrôle de l’écran, par exemple lorsqu’elle passe en arrière-plan.
dismiss() passe par la chaîne de traitement de fin habituelle du SDK : il ferme l’interface présentée, réinitialise l’état interne et appelle le gestionnaire .diditVerification avec .cancelled(session:), qui transporte le sessionId courant si une session a été créée. Cette méthode est sans effet lorsqu’aucune vérification n’est active.
Exemple de fermeture lorsque l’application passe en arrière-plan
Observer l’état du SDK
Vous pouvez observer l’état du SDK pour personnaliser l’interface de chargement :Exemple de bout en bout (session backend → SDK iOS → résultat)
Ce schéma correspond à une intégration prête pour la production. Votre backend crée la session, votre application iOS reçoit lesession_token, et le SDK exécute le parcours.