GitHub Repository
View source code, releases, and the complete changelog on GitHub
Requirements
iOS Version Compatibility
Biometric consent needs native 4.10.0 or later. For people covered by Illinois, Texas or Colorado law, Didit can ask for explicit biometric consent before the first face capture. iOS SDK 4.10.0 and later show that step. Earlier versions cannot show the step: their sessions run as before, and the decision reports the consent as not collected (
biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Upgrade if you verify people in those states.Installation
Since4.0.0 the SDK ships in several installable variants, so your app only pays the binary cost of the features it uses. Pick exactly one variant — one CocoaPods subspec and one SwiftPM library product:
- Core — smallest footprint, with automatic document and selfie capture on Didit’s own lightweight detectors. No
OpenSSL.xcframework, no CoreNFC runtime. - AutoDetection — deprecated since 4.11.0 and identical to Core; use Core instead.
- NFC — Core plus NFC passport/eID chip reading.
- All — every feature. This is the default when you install
DiditSDKwithout naming a subspec/product.
4.9.0): Core ~11.1 MB, NFC ~11.7 MB plus ~4 MB of OpenSSL, AutoDetection ~16.0 MB, All ~16.6 MB plus OpenSSL.
The detection models themselves are downloaded at runtime and cached, so they never count against your app’s download size.
Since 4.11.0 automatic capture runs on Didit’s own lightweight detectors in every variant. TensorFlow Lite is no longer part of the SDK, and the framework is smaller because its translations are loaded from outside the binary.
Since 4.6.0 the shipped frameworks no longer carry Swift ABI descriptors (build metadata Xcode copied into every app but never read) or tutorial videos the variant cannot play — upgrading from 4.5.4 or earlier shrinks your app by roughly 7-8 MB on its own, with no code changes.
The App Store compresses binaries for delivery, so the over-the-air cost is lower — check App Store Connect’s app size report for the exact per-device delta.
The NFC and All variants bundle
OpenSSL.xcframework (OpenSSL 3.3.3, shipped as OpenSSL-Universal 3.3.3001 via NFCPassportReader), which is required for NFC chip authentication and needs iOS 15.0+. Releases up to and including 4.0.6 bundled OpenSSL 1.1.1s; 4.0.7 and later ship OpenSSL 3.3.3 with its own privacy manifest and code signature — always install 4.0.7 or later. Note that upgrading aligns OpenSSL versions but does not remove embed collisions: if another dependency in your app also embeds an OpenSSL.framework (same filename, same com.github.krzyzanowskim.OpenSSL bundle id), the two copies collide at the embed step regardless of version. Keep exactly one copy — for example, override the other package by SPM identity to use the Didit-published OpenSSL.xcframework, so the binary in the bundle is the one this SDK was built against. The Core and AutoDetection variants link no OpenSSL at all.import DiditSDK is the same in your app code regardless of the variant you install.
Swift Package Manager (Recommended)
Add the package to your project using Xcode:- Go to File > Add Package Dependencies
- Enter the repository URL:
- Select the version (or Up to Next Major from
4.15.1) and click Add Package - When prompted to choose a product, pick exactly one library product for your variant (see the table above)
Package.swift:
CocoaPods
DiditSDK is distributed as a binary podspec hosted in the repo (it is not on the public CocoaPods Trunk), so you must reference the podspec URL. Pick exactly one subspec:
Core and AutoDetection deploy down to iOS 13; NFC and All require iOS 15 because of NFCPassportReader.
Then run:
After
pod install, open the generated .xcworkspace (not .xcodeproj).Xcode 15+ rsync errors: If you see
Operation not permitted rsync errors during build, set Build Settings → User Script Sandboxing (ENABLE_USER_SCRIPT_SANDBOXING) to No on the project for both Debug and Release.Manual (XCFramework)
Each release publishes one XCFramework per variant. Download the zips for your variant from the GitHub Releases page, then drag the.xcframework folders into Xcode and set Embed & Sign.
Permissions
The SDK requires the following permissions. Add these to your app’sInfo.plist:
Example Info.plist Entries
NFC Configuration
Required only when installing the NFC or All variant. Skip this section if you installed the Core or AutoDetection variant. To enable NFC reading for passports and ID cards with chips:-
Add NFC Capability in Xcode:
- Select your target → Signing & Capabilities → + Capability → Near Field Communication Tag Reading
-
Add ISO7816 Identifiers to
Info.plist:
D392F000260100000001 lets the SDK read the Japan My Number Card through JPKI: without it, iOS does not report the card to the SDK. My Number Card reading is not enabled in production yet, and the identifier changes nothing for other documents, so you can add it now.
- Add Entitlements (in your
.entitlementsfile):
App Store Review (NFC and All variants): If you install the NFC or All variant, Apple may request a demo video during review because NFC-related code is part of the SDK binary — even if your workflow does not use NFC. Request our NFC demo video to submit to Apple from support@didit.me. This does not apply to the Core or AutoDetection variant.
Quick Start
SwiftUI Integration
UIKit Integration
Integration Methods
The SDK supports two integration methods:Method 1: UniLink (Simplest)
No backend required. The SDK creates the session directly using your workflow ID from the Didit Console. The UniLink method (startVerification(workflowId:)) only supports vendorData; for any other session parameters use Method 2.
For
vendorData to be attached to the session via UniLink, enable the Vendor Data option in the Didit Console.Method 2: Backend Session (Recommended for Production)
Your backend creates the session via the Create Verification Session API (POST /v3/session/) with full parameter support (contact_details, expected_details, metadata, callback, etc.), then passes the session_token to the SDK.
- Associating sessions with your users (
vendor_data) - Setting contact details and expected details for cross-validation
- Setting custom metadata
- Configuring callbacks per session This data (contact details, expected details, metadata, callback) is sent to the Create Verification Session API.
Configuration
Customize the SDK behavior withDiditSdk.Configuration:
Configuration Options
Camera options
The camera options match the Web SDK camera options. Each lens is.front or .back.
If the device does not have the requested lens, the SDK uses the first camera it has.
The camera switcher is also hidden on devices that have only one camera.
Set a switcher option to false to lock the user to the default lens of that step.
Theming & Colors: Colors, backgrounds, and intro screen settings are configured through your White Label settings in the Didit Console, not in the SDK configuration. This ensures consistent branding across all platforms.
Options
showLanguageSelector, showCloseButton, showExitConfirmation, and closeOnComplete match the Web SDK’s DiditSdkConfiguration. Mobile-specific options languageLocale and fontFamily exist because the mobile SDK renders the full verification UI natively (unlike the Web SDK which delegates to the hosted frontend inside an iframe).Language Support
The SDK supports 54 languages. If no language is specified, the SDK uses the device locale with English as fallback.Advanced Session Parameters
For advanced session parameters (contact_details, expected_details, metadata, callback), use the Backend Session method. Your backend calls the Create Verification Session API with full parameters, then passes the session_token to the SDK.
Handling Results
TheVerificationResult enum provides the outcome of the verification:
Result Cases
SessionData Properties
Error Types
Lost connection
If the device loses its connection during the verification, the SDK covers the flow with a “No internet connection” screen instead of leaving a step loading. It keeps checking in the background and closes the screen by itself as soon as Didit can be reached again, and the user carries on from the step they were on. The screen offers Try Again and, whenshowCloseButton is true (the default), Exit Verification.
Exiting ends the verification with .failed(error: .networkError, session:), so your app knows the user left because of the connection.
Complete Result Handling Example
Dismissing the Verification Programmatically
Available in DiditSDK 3.6.0+.
DiditSdk.shared.dismiss(). This is the recommended way to tear down the verification when the host needs to take over the screen — for example, when the app moves to the background.
dismiss() goes through the SDK’s normal completion pipeline: it dismisses the presented UI, resets internal state, and invokes the .diditVerification handler with .cancelled(session:) carrying the current sessionId if a session was created. It is a no-op when no verification is active.
Example: dismiss when the app backgrounds
Observing SDK State
You can observe the SDK state for custom loading UI:End-to-End Example (Backend Session → iOS SDK → Result)
This pattern is the production-ready integration. Your backend creates the session, your iOS app receives thesession_token, and the SDK runs the flow.