Skip to main content
A lightweight, server-driven iOS SDK for identity verification with minimal configuration required. Latest version: 4.6.0.

GitHub Repository

View source code, releases, and the complete changelog on GitHub

Requirements

iOS Version Compatibility


Installation

Since 4.0.0 the SDK ships in four 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, manual capture only. No OpenSSL.xcframework, no CoreNFC runtime, no MediaPipe.
  • AutoDetection — ML-based document/face auto-capture, but no NFC chip reading.
  • NFC — NFC passport/eID chip reading without the auto-capture ML runtime.
  • All — every feature. This is the default when you install DiditSDK without naming a subspec/product.
What each variant adds to your app bundle (device-slice framework, measured against 4.6.0): Core ~13 MB, NFC ~14 MB plus ~4 MB of OpenSSL, AutoDetection ~25 MB, All ~26 MB plus OpenSSL. Auto-capture accounts for ~12 MB of that (the ML runtime); the detection models themselves are downloaded at runtime and cached, so they never count against your app’s download size. 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. Add the package to your project using Xcode:
  1. Go to File > Add Package Dependencies
  2. Enter the repository URL:
  1. Select the version (or Up to Next Major from 4.6.0) and click Add Package
  2. When prompted to choose a product, pick exactly one library product for your variant (see the table above)
Or in your Package.swift:
Then add exactly one of these products to your target:
Swift Package Manager does not enforce the iOS 15 floor for you. Package.swift declares platforms: [.iOS(.v13)] for the whole package, so Xcode will let you add DiditSDK or DiditSDKNFC to an iOS 13 or 14 target without complaint — but both bundle OpenSSL.xcframework and read chips through NFCPassportReader, which need iOS 15.0+. Set your target’s deployment target to 15.0 yourself when using the All or NFC product. CocoaPods enforces this automatically via the subspec’s deployment_target.

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’s Info.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:
  1. Add NFC Capability in Xcode:
    • Select your target → Signing & Capabilities+ CapabilityNear Field Communication Tag Reading
  2. Add ISO7816 Identifiers to Info.plist:
  1. Add Entitlements (in your .entitlements file):
Simulator Limitation (NFC and All variants): These variants link CoreNFC, and since Xcode 12 libnfshared.dylib is missing from simulators. See this Stack Overflow thread for a workaround. This does not apply to the Core or AutoDetection variant. Test NFC features on physical devices only.

Quick Start

SwiftUI Integration

UIKit Integration


Integration Methods

The SDK supports two integration methods: 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.
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.
This approach gives you full control over:
  • 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 with DiditSdk.Configuration:

Configuration Options

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 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 53 languages. If no language is specified, the SDK uses the device locale with English as fallback.
View All Supported Languages →

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

The VerificationResult enum provides the outcome of the verification:

Result Cases

SessionData Properties

Error Types

Complete Result Handling Example


Dismissing the Verification Programmatically

Available in DiditSDK 3.6.0+.
The host app can end an active verification programmatically with 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

Do not set DiditSdk.shared.isPresented = false to dismiss — the flag only triggers presentation on its rising edge and setting it to false is a no-op. Likewise, calling UIKit’s dismiss(animated:) on the topmost view controller is not supported: it bypasses the SDK’s completion pipeline so your .diditVerification handler is never fired.

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 the session_token, and the SDK runs the flow.

1. Backend — create the session

2. iOS — exchange and start the SDK

3. Backend — receive the final decision via webhook

The SDK result is convenient for UI feedback, but the authoritative outcome arrives via webhook. See the Webhooks guide for HMAC verification.

Complete SwiftUI Example