Zum Hauptinhalt springen
Ein schlankes, serverbasiertes iOS-SDK für die Identitätsverifizierung, das nur minimale Konfiguration erfordert. Neueste Version: 4.13.2.

GitHub-Repository

Quellcode, Releases und das vollständige Changelog auf GitHub ansehen

Native SDK: Dies ist der empfohlene Ansatz für iOS-Apps. Native SDKs bieten die beste Nutzererfahrung, optimierte Kamerasteuerung und volle NFC-Unterstützung.


Voraussetzungen

iOS-Versionskompatibilität

Biometrische Einwilligung erfordert das native SDK ab Version 4.10.0. Für Personen, die unter die Gesetze von Illinois, Texas oder Colorado fallen, kann Didit vor der ersten Gesichtserfassung eine ausdrückliche biometrische Einwilligung einholen. Das iOS-SDK ab Version 4.10.0 zeigt diesen Schritt an. Ältere Versionen können den Schritt nicht anzeigen: Ihre Sitzungen laufen wie zuvor ab, und die Entscheidung meldet die Einwilligung als nicht erfasst (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Führen Sie ein Upgrade durch, wenn Sie Personen in diesen Bundesstaaten verifizieren.

Installation

Seit 4.0.0 wird das SDK in mehreren installierbaren Varianten ausgeliefert, sodass Ihre App nur die Binärgröße der Funktionen trägt, die sie tatsächlich nutzt. Wählen Sie genau eine Variante aus, also genau ein CocoaPods-Subspec und genau ein SwiftPM-Bibliotheksprodukt:
  • Core: der kleinste Footprint, mit automatischer Dokument- und Selfie-Aufnahme über die eigenen schlanken Detektoren von Didit. Kein OpenSSL.xcframework, keine CoreNFC-Laufzeitumgebung.
  • AutoDetection: seit 4.11.0 veraltet und identisch mit Core. Verwenden Sie stattdessen Core.
  • NFC: Core plus das Auslesen von NFC-Chips in Reisepässen und eID-Karten.
  • All: alle Funktionen. Dies ist die Standardvariante, wenn Sie DiditSDK ohne Angabe eines Subspecs oder Produkts installieren.
Was jede Variante zum App-Bundle hinzufügt (arm64 Mach-O, gemessen an 4.9.0): Core etwa 11,1 MB, NFC etwa 11,7 MB plus etwa 4 MB OpenSSL, AutoDetection etwa 16,0 MB, All etwa 16,6 MB plus OpenSSL. Die Erkennungsmodelle selbst werden zur Laufzeit heruntergeladen und zwischengespeichert, sodass sie niemals in die Download-Größe Ihrer App eingerechnet werden. Seit 4.11.0 läuft die automatische Aufnahme in jeder Variante über die eigenen schlanken Detektoren von Didit. TensorFlow Lite ist nicht mehr Bestandteil des SDK, und das Framework ist kleiner, weil seine Übersetzungen von außerhalb der Binärdatei geladen werden. Seit 4.6.0 enthalten die ausgelieferten Frameworks keine Swift-ABI-Deskriptoren (Build-Metadaten, die Xcode in jede App kopiert, aber nie liest) und keine Tutorial-Videos, die die Variante nicht abspielen kann. Wenn Sie von 4.5.4 oder einer früheren Version aktualisieren, wird Ihre App allein dadurch um etwa 7-8 MB kleiner, ohne Codeänderungen. Der App Store komprimiert Binärdateien für die Auslieferung, daher fallen die Kosten der Over-the-Air-Übertragung geringer aus. Den genauen Unterschied pro Gerät finden Sie im App-Größenbericht in App Store Connect.
Die Varianten NFC und All bündeln OpenSSL.xcframework (OpenSSL 3.3.3, ausgeliefert als OpenSSL-Universal 3.3.3001 über NFCPassportReader), das für die NFC-Chip-Authentifizierung erforderlich ist und iOS 15.0+ voraussetzt. Releases bis einschließlich 4.0.6 bündelten OpenSSL 1.1.1s; ab 4.0.7 wird OpenSSL 3.3.3 mit eigenem Privacy-Manifest und eigener Code-Signatur ausgeliefert. Installieren Sie daher immer 4.0.7 oder neuer. Beachten Sie, dass das Upgrade zwar die OpenSSL-Versionen angleicht, aber keine Embed-Konflikte beseitigt: Wenn eine andere Abhängigkeit in Ihrer App ebenfalls ein OpenSSL.framework einbettet (gleicher Dateiname, gleiche Bundle-ID com.github.krzyzanowskim.OpenSSL), kollidieren beide Kopien im Embed-Schritt unabhängig von der Version. Behalten Sie genau eine Kopie bei, zum Beispiel indem Sie das andere Paket anhand seiner SPM-Identität überschreiben, um das von Didit veröffentlichte OpenSSL.xcframework zu verwenden. So ist die Binärdatei im Bundle dieselbe, gegen die dieses SDK gebaut wurde. Die Varianten Core und AutoDetection binden überhaupt kein OpenSSL ein.
import DiditSDK ist in Ihrem App-Code unabhängig von der installierten Variante gleich.

Swift Package Manager (empfohlen)

Fügen Sie das Paket mit Xcode zu Ihrem Projekt hinzu:
  1. Öffnen Sie File > Add Package Dependencies
  2. Geben Sie die Repository-URL ein:
  1. Wählen Sie die Version (oder Up to Next Major ab 4.13.2) und klicken Sie auf Add Package
  2. Wenn Sie aufgefordert werden, ein Produkt auszuwählen, wählen Sie genau ein Bibliotheksprodukt für Ihre Variante (siehe Tabelle oben)
Oder in Ihrer Package.swift:
Fügen Sie dann genau eines dieser Produkte zu Ihrem Target hinzu:
Swift Package Manager erzwingt die Untergrenze iOS 15 nicht für Sie. Package.swift deklariert platforms: [.iOS(.v13)] für das gesamte Paket. Xcode lässt Sie daher DiditSDK oder DiditSDKNFC ohne Beanstandung zu einem iOS-13- oder iOS-14-Target hinzufügen. Beide bündeln jedoch OpenSSL.xcframework und lesen Chips über NFCPassportReader, was iOS 15.0+ voraussetzt. Setzen Sie das Deployment-Target Ihres Targets selbst auf 15.0, wenn Sie das Produkt All oder NFC verwenden. CocoaPods erzwingt dies automatisch über das deployment_target des Subspecs.

CocoaPods

DiditSDK wird als binäres Podspec im Repository bereitgestellt. Es ist nicht im öffentlichen CocoaPods-Trunk verfügbar, daher müssen Sie die URL des Podspecs angeben. Wählen Sie genau ein Subspec aus:
Core und AutoDetection unterstützen iOS 13 als Mindestversion. NFC und All erfordern iOS 15 wegen NFCPassportReader. Führen Sie danach aus:
Öffnen Sie nach pod install die erzeugte .xcworkspace-Datei (nicht die .xcodeproj-Datei).
rsync-Fehler in Xcode 15+: Wenn während des Builds rsync-Fehler mit Operation not permitted auftreten, setzen Sie Build Settings → User Script Sandboxing (ENABLE_USER_SCRIPT_SANDBOXING) für das Projekt sowohl für Debug als auch für Release auf No.

Manuell (XCFramework)

Jedes Release veröffentlicht ein XCFramework pro Variante. Laden Sie die ZIP-Dateien für Ihre Variante von GitHub Releases herunter, ziehen Sie dann die .xcframework-Ordner in Xcode und setzen Sie Embed & Sign.

Berechtigungen

Das SDK erfordert die folgenden Berechtigungen. Fügen Sie diese der Info.plist Ihrer App hinzu:

Beispielhafte Info.plist-Einträge

NFC-Konfiguration

Nur erforderlich bei der Installation der Variante NFC oder All. Überspringen Sie diesen Abschnitt, wenn Sie die Variante Core oder AutoDetection installiert haben. So aktivieren Sie das Auslesen von NFC-Chips für Reisepässe und Ausweise mit Chip:
  1. NFC-Capability hinzufügen in Xcode:
    • Wählen Sie Ihr Target aus → Signing & Capabilities → + Capability → Near Field Communication Tag Reading
  2. ISO7816-Identifikatoren hinzufügen zu Info.plist:
D392F000260100000001 ermöglicht dem SDK das Auslesen der japanischen My Number Card über JPKI: Ohne diesen Identifikator gibt iOS die Karte nicht an das SDK weiter. Das Auslesen der My Number Card ist in der Produktion noch nicht aktiviert, und der Identifikator ändert nichts für andere Dokumente, sodass Sie ihn bereits jetzt hinzufügen können.
  1. Entitlements hinzufügen (in Ihrer .entitlements-Datei):
Simulator-Einschränkung (NFC- und All-Varianten): Diese Varianten binden CoreNFC ein, und seit Xcode 12 fehlt libnfshared.dylib in Simulatoren. Siehe diesen Stack-Overflow-Thread für einen Workaround. Dies gilt nicht für die Variante Core oder AutoDetection. Testen Sie NFC-Funktionen ausschließlich auf physischen Geräten.

App-Store-Prüfung (NFC- und All-Varianten): Wenn Sie die Variante NFC oder All installieren, verlangt Apple während der Prüfung möglicherweise ein Demo-Video, da NFC-bezogener Code Teil der SDK-Binärdatei ist – selbst wenn Ihr Workflow kein NFC verwendet. Fordern Sie unser NFC-Demo-Video zur Einreichung bei Apple unter support@didit.me an. Dies gilt nicht für die Variante Core oder AutoDetection.


Schnellstart

SwiftUI-Integration

UIKit-Integration


Integrationsmethoden

Das SDK unterstützt zwei Integrationsmethoden: Kein Backend erforderlich. Das SDK erstellt die Sitzung direkt mit Ihrer Workflow-ID aus der Didit Console. Die UniLink-Methode (startVerification(workflowId:)) unterstützt nur vendorData; für alle anderen Sitzungsparameter verwenden Sie Methode 2.
Damit vendorData über UniLink an die Sitzung angehängt werden kann, aktivieren Sie die Option Vendor Data in der Didit Console.

Methode 2: Backend-Sitzung (Empfohlen für die Produktion)

Ihr Backend erstellt die Sitzung über die Create Verification Session API (POST /v3/session/) mit vollständiger Parameterunterstützung (contact_details, expected_details, metadata, callback usw.) und übergibt anschließend das session_token an das SDK.
Dieser Ansatz gibt Ihnen die volle Kontrolle über:
  • Die Verknüpfung von Sitzungen mit Ihren Benutzern (vendor_data)
  • Das Festlegen von Kontaktdaten und erwarteten Details für den Kreuzabgleich
  • Das Setzen benutzerdefinierter Metadaten
  • Das Konfigurieren von Callbacks pro Sitzung Diese Daten (Kontaktdaten, erwartete Details, Metadaten, Callback) werden an die Create Verification Session API gesendet.

Konfiguration

Passen Sie das Verhalten des SDKs mit DiditSdk.Configuration an:

Konfigurationsoptionen

Kameraoptionen

Die Kameraoptionen entsprechen den Web-SDK-Kameraoptionen. Jedes Objektiv ist .front oder .back. Wenn das Gerät nicht über das angeforderte Objektiv verfügt, verwendet das SDK die erste verfügbare Kamera. Auf Geräten mit nur einer Kamera wird der Kamerawechsler ebenfalls ausgeblendet. Setzen Sie eine Kamerawechseloption auf false, um den Benutzer auf das Standardobjektiv dieses Schritts festzulegen.
Gestaltung und Farben: Farben, Hintergründe und Einstellungen für den Startbildschirm werden über Ihre White-Label-Einstellungen in der Didit Console konfiguriert, nicht in der SDK-Konfiguration. Dies gewährleistet ein einheitliches Branding über alle Plattformen hinweg.
Die Optionen showLanguageSelector, showCloseButton, showExitConfirmation und closeOnComplete entsprechen der DiditSdkConfiguration des Web SDKs. Die mobilspezifischen Optionen languageLocale und fontFamily existieren, da das mobile SDK die gesamte Verifizierungs-UI nativ rendert (im Gegensatz zum Web SDK, das dies an das gehostete Frontend innerhalb eines iFrames delegiert).

Sprachunterstützung

Das SDK unterstützt 54 Sprachen. Wenn keine Sprache angegeben wird, verwendet das SDK die Geräte-Locale mit Englisch als Fallback.
Alle unterstützten Sprachen anzeigen →

Erweiterte Sitzungsparameter

Verwenden Sie für erweiterte Sitzungsparameter (contact_details, expected_details, metadata, callback) die Methode Backend-Sitzung. Ihr Backend ruft die API zur Erstellung von Verifizierungssitzungen mit allen Parametern auf und übergibt anschließend das session_token an das SDK.

Ergebnisse verarbeiten

Das VerificationResult-Enum liefert das Ergebnis der Verifizierung:

Ergebnisfälle

SessionData-Eigenschaften

Fehlertypen

Verbindungsabbruch

Wenn das Gerät während der Verifizierung die Verbindung verliert, blendet das SDK anstelle eines ladenden Schritts einen Bildschirm mit dem Hinweis „Keine Internetverbindung“ ein. Es prüft die Verbindung im Hintergrund weiter und schließt den Bildschirm automatisch, sobald Didit wieder erreichbar ist, sodass der Benutzer an dem Schritt fortfahren kann, an dem er sich befand. Der Bildschirm bietet Erneut versuchen und, wenn showCloseButton auf true gesetzt ist (Standardwert), Verifizierung beenden. Das Beenden beendet die Verifizierung mit .failed(error: .networkError, session:), sodass Ihre App erkennt, dass der Benutzer den Vorgang aufgrund des Verbindungsabbruchs verlassen hat.

Vollständiges Beispiel für die Ergebnisverarbeitung


Schließen der Verifizierung per Programmcode

Verfügbar in DiditSDK 3.6.0+.
Die Host-App kann eine aktive Verifizierung programmgesteuert mit DiditSdk.shared.dismiss() beenden. Dies ist die empfohlene Methode, um die Verifizierung zu beenden, wenn die Host-App den Bildschirm übernehmen muss – beispielsweise, wenn die App in den Hintergrund wechselt.
dismiss() durchläuft die reguläre Abschluss-Pipeline des SDK: Es schließt die angezeigte Benutzeroberfläche, setzt den internen Status zurück und ruft den .diditVerification-Handler mit .cancelled(session:) auf, der die aktuelle sessionId enthält, sofern eine Sitzung erstellt wurde. Es ist ein No-Op, wenn keine Verifizierung aktiv ist.

Beispiel: Schließen, wenn die App in den Hintergrund wechselt

Setzen Sie DiditSdk.shared.isPresented = false nicht, um die Ansicht zu schließen – das Flag löst die Anzeige nur bei einer steigenden Flanke aus, und das Setzen auf false ist ein No-Op. Ebenso wird das Aufrufen von UIKit-dismiss(animated:) auf dem obersten View Controller nicht unterstützt: Es umgeht die Abschluss-Pipeline des SDK, sodass Ihr .diditVerification-Handler niemals ausgelöst wird.

Beobachten des SDK-Status

Sie können den SDK-Status beobachten, um eine benutzerdefinierte Ladeoberfläche anzuzeigen:

End-to-End-Beispiel (Backend-Sitzung → iOS-SDK → Ergebnis)

Dieses Muster ist die produktionsreife Integration. Ihr Backend erstellt die Sitzung, Ihre iOS-App empfängt das session_token und das SDK führt den Workflow aus.

1. Backend – Sitzung erstellen

2. iOS – Austausch und SDK starten

3. Backend – Endgültige Entscheidung per Webhook empfangen

Das SDK-Ergebnis eignet sich für Feedback in der Benutzeroberfläche, das verbindliche Ergebnis trifft jedoch per Webhook ein. Informationen zur HMAC-Prüfung finden Sie im Webhook-Leitfaden.

Vollständiges SwiftUI-Beispiel


Zuletzt geändert am 7. November 2026