# Mobile und Web-SDKs

Source: https://help.didit.me/de/integration/mobile-sdks
Updated: 2026-10-12

Native SDKs für iOS, Android, React Native und Flutter binden den Ablauf in Ihre App ein und sind der einzige Weg zu NFC. Web-SDKs ergänzen das Frontend.

Native SDKs gibt es für **iOS, Android, React Native und Flutter**; Web-SDKs betten
den Ablauf in Ihr Frontend ein. Nutzen Sie ein natives SDK, wenn Sie **NFC** oder das beste
Kameraverhalten benötigen - eine WebView bietet keines von beidem. Ergebnisse kommen weiterhin per
Webhook zurück, nicht vom SDK.

## Warum ein SDK statt eines Redirects

[Video: Der vollständige Integrationsleitfaden - Didit Academy](https://www.youtube.com/watch?v=fX03-WEu_EI)

Ein gehostetes Redirect ist der geringste Aufwand und für die meisten Abläufe wirklich ausreichend. Ein SDK lohnt sich, wenn:

- **Sie NFC benötigen.** Der Chip in einem Reisepass oder Ausweis kann von einer Browserseite aus nicht ausgelesen werden. Ein natives SDK ist der einzige Weg. Siehe [NFC-Chip-Verifizierung](https://help.didit.me/de/documents-coverage/nfc-chip-verification).
- **Sie möchten nicht, dass der Nutzer Ihre App verlässt.** Ein Redirect nach draußen und zurück ist auf Mobilgeräten ein echter Abbruchpunkt.
- **Sie möchten das beste Kameraverhalten.** Nativer Kamerazugriff ist zuverlässiger als der eines Browsers, besonders auf älteren Geräten.

## Was verfügbar ist

[Video: Das richtige Didit-SDK wählen - Didit Academy](https://www.youtube.com/watch?v=qHada8ZY24Q&t=14)

| Plattform | Hinweise |
|---|---|
| **iOS** | Als XCFramework verteilt |
| **Android** | Über Maven verteilt |
| **React Native** | Umschließt die nativen Module; unterstützt die New Architecture |
| **Flutter** | Umschließt die nativen Module |
| **JavaScript / Web** | Bettet den gehosteten Ablauf in Ihr Web-Frontend ein |
| **In-Context-iFrame** | Rendert den Ablauf innerhalb Ihrer Seite, statt weiterzuleiten |

![Die Seite Integrate in der Didit-Konsole mit den Links zu SDK und Dokumentation](https://help.didit.me/screenshots/integrate-light.webp)

*Jedes SDK startet von derselben Seite wie die API.*

iOS unterstützt Swift Package Manager und CocoaPods; ergänze bei Bedarf Kamera- und NFC-Berechtigungen in `Info.plist`. Android wird über Maven verteilt. React Native unterstützt Expo mit einem Development Build inklusive nativer Module, nicht mit Expo Go.

Versionsanforderungen und Plattform-Mindestwerte ändern sich mit neuen Releases, prüfen Sie also die aktuelle [SDK-Dokumentation](https://docs.didit.me/integration/native-sdks/overview) statt einer Momentaufnahme dieser Hilfeseite - und wenn Sie eine bestimmte Framework-Version einsetzen (etwa ein bestimmtes Expo-SDK), bestätigen Sie die Kompatibilität mit Ihrem Didit-Ansprechpartner, bevor Sie sich in einem Sprint darauf festlegen.

## Eine WebView ist kein natives SDK

Den gehosteten Web-Ablauf in eine WebView einzupacken, wirkt, als gäbe es Ihnen eine In-App-Erfahrung. Sie gibt Ihnen den Anschein davon:

- **Kein NFC.** Der Chip lässt sich weiterhin nicht auslesen.
- **Kamera-Berechtigungen sind schwieriger.** Der Kamerazugriff einer WebView hängt von der Konfiguration der Host-App ab, und ihn falsch einzurichten erzeugt genau die "die Kamera hat sich nie geöffnet"-Meldungen, die in [Probleme mit Liveness-Prüfung und Gesichtsabgleich beheben](https://help.didit.me/de/liveness-biometrics/liveness-and-face-match-issues) behandelt werden.
- **Die Locale gehört der App, nicht dem Nutzer.** Eine WebView meldet die Locale der Host-App, übergeben Sie also `language` explizit beim Erstellen der Session. Siehe [die Verifizierungssprache festlegen](https://help.didit.me/de/workflows/verification-languages).

Wenn Sie sich schon die Mühe eines In-App-Ablaufs machen, nutzen Sie das native SDK.

## Ergebnisse kommen weiterhin von Webhooks

Das überrascht viele: Das SDK teilt Ihrer App mit, dass der Nutzer den Ablauf abgeschlossen hat. Es ist **nicht** die maßgebliche Quelle für die Verifizierungsentscheidung.

Die Entscheidung wird serverseitig erzeugt, nachdem die Prüfungen gelaufen sind, und erreicht Sie per [Webhook](https://help.didit.me/de/integration/webhooks-basics). Gewähren Sie niemals Zugriff allein aufgrund des Completion-Callbacks des SDK - ein clientseitiges Signal ist trivial fälschbar, und die Prüfungen sind unter Umständen noch nicht einmal abgeschlossen, wenn er ausgelöst wird.

> **Warning:** "Das SDK hat fertig gemeldet" mit "der Nutzer ist verifiziert" gleichzusetzen, ist der folgenreichste
> Fehler, der bei einer mobilen Integration möglich ist. Bestätigen Sie es auf Ihrem Server, über den
> Webhook oder den Decision-Endpoint, bevor Sie irgendetwas freischalten.

## Eine Verbraucher-App, oder Ihre eigene?

Es gibt keine separate Verbraucher-App von Didit, an die eine gehostete Session Nutzer für einen Schritt wie NFC übergibt. Wenn Sie alles - NFC und Nicht-NFC - innerhalb einer einzigen App-Erfahrung wollen, ist diese App **Ihre eigene**, mit eingebettetem SDK.

## Verteilung und Abhängigkeitskonflikte

Die Integration des nativen SDK kollidiert gelegentlich mit anderen Abhängigkeiten in einer Host-App - einer gemeinsam genutzten transitiven Bibliothek, oder einer Subspec, die eine Version fixiert, die auch etwas anderes fixiert. Wenn Sie darauf stoßen, ist das ein konkretes, reproduzierbares Problem, das eine Meldung mit Ihrem Dependency-Manifest wert ist, statt es durch Fixieren einer alten Version zu umgehen: die Korrektur gehört meist in das SDK.

## Auf einem Gerät testen

Wechseln Sie mit dem Schalter unter dem Anwendungsnamen zu **Sandbox**, erstellen Sie dort einen API-Schlüssel und verwenden Sie ihn. Prüfungen werden simuliert, nicht berechnet, und Sie können das Ergebnis wählen.

[Testen in der Sandbox](https://help.didit.me/de/getting-started/sandbox-and-testing)