Passer au contenu principal
Un SDK iOS léger, piloté par le serveur, pour la vérification d’identité avec une configuration minimale. Dernière version : 4.13.2.

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 version 4.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 DiditSDK sans nommer de sous-spécification ni de produit.
Ce que chaque variante ajoute au bundle de votre application (Mach-O arm64, mesuré avec la version 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 :
  1. Allez dans File > Add Package Dependencies
  2. Saisissez l’URL du dépôt :
  1. Sélectionnez la version (ou Up to Next Major à partir de 4.13.2), puis cliquez sur Add Package
  2. Lorsqu’on vous demande de choisir un produit, sélectionnez exactement un produit de bibliothèque correspondant à votre variante (voir le tableau ci-dessus)
Ou dans votre Package.swift :
Ajoutez ensuite exactement un de ces produits à votre cible :
Swift Package Manager n’applique pas à votre place le minimum iOS 15. Package.swift déclare platforms: [.iOS(.v13)] pour l’ensemble du paquet. Xcode vous laissera donc ajouter DiditSDK ou DiditSDKNFC à une cible iOS 13 ou 14 sans broncher. Or ces deux produits embarquent OpenSSL.xcframework et lisent les puces via NFCPassportReader, qui exigent iOS 15.0+. Réglez vous-même la version minimale de déploiement de votre cible sur 15.0 lorsque vous utilisez le produit All ou NFC. CocoaPods applique cette règle automatiquement grâce au paramètre deployment_target de la sous-spécification.

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 fichier Info.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 :
  1. Ajoutez la capacité NFC dans Xcode :
    • Sélectionnez votre cible → Signing & Capabilities → + Capability → Near Field Communication Tag Reading
  2. 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.
  1. Ajoutez les droits (dans votre fichier .entitlements) :
Limitation du simulateur (variantes NFC et All) : Ces variantes lient CoreNFC, et depuis Xcode 12, libnfshared.dylib est absent des simulateurs. Consultez ce fil Stack Overflow pour une solution de contournement. Cela ne s’applique pas aux variantes Core ou AutoDetection. Testez les fonctionnalités NFC uniquement sur des appareils physiques.

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 : 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.
Cette approche vous donne un contrôle total sur :
  • 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
Ces données (coordonnées, informations attendues, métadonnées, callback) sont envoyées à l’API de création de session de vérification.

Configuration

Personnalisez le comportement du SDK avec DiditSdk.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.
Voir toutes les langues prises en charge →

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ération VerificationResult 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, lorsque showCloseButton 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+.
L’application hôte peut mettre fin à une vérification en cours par programmation avec 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

Ne définissez pas DiditSdk.shared.isPresented = false pour fermer la vérification : cet indicateur ne déclenche la présentation que sur son front montant, et le mettre à false est sans effet. De même, appeler dismiss(animated:) d’UIKit sur le contrôleur de vue au sommet n’est pas pris en charge : cela contourne la chaîne de traitement de fin du SDK, si bien que votre gestionnaire .diditVerification n’est jamais déclenché.

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 le session_token, et le SDK exécute le parcours.

1. Côté backend, création de la session

2. Côté iOS, échange du token et démarrage du SDK

3. Côté backend, réception de la décision finale par webhook

Le résultat du SDK est pratique pour le retour à l’utilisateur, mais le résultat faisant autorité est transmis par webhook. Consultez le guide des webhooks pour la vérification HMAC.

Exemple SwiftUI complet


Dernière modification le 7 novembre 2026