Mobile and web SDKs

Native SDKs for iOS, Android, React Native and Flutter put the flow inside your app and are the only route that supports NFC. Web SDKs embed it in your frontend.

Written by Didit Support · Updated 19 August 2026

#Why an SDK rather than a redirect

A hosted redirect is the least work and is genuinely fine for most flows. An SDK is worth it when:

• You need NFC. The chip in a passport or ID cannot be read from a browser page. A native SDK is the only route. See NFC chip verification.
• You don't want the user to leave your app. A redirect out and back is a real drop-off point on mobile.
• You want the best camera behaviour. Native camera access is more reliable than a browser's, especially on older devices.

#What's available

12

1. Pick your platform and the page gives you that stack's snippet.
2. The native and web SDKs, each with its own quickstart, are linked here.

Version requirements and platform minimums change with releases, so check the current SDK documentation rather than a help-page snapshot - and if you're on a specific framework version (a particular Expo SDK, for example), confirm compatibility with your Didit contact before committing to it in a sprint.

#A WebView is not a native SDK

Wrapping the hosted web flow in a WebView looks like it gives you an in-app experience. It gives you the appearance of one:

• No NFC. The chip still can't be read.
• Camera permissions are harder. A WebView's camera access depends on host-app configuration, and getting it wrong produces exactly the "the camera never opened" reports covered in fixing liveness and face match problems.
• Locale is the app's, not the user's. A WebView reports the host app's locale, so pass language explicitly on session create. See setting the verification language.

If you're going to the trouble of an in-app flow, use the native SDK.

#Results still come from webhooks

This catches people out: the SDK tells your app that the user finished the flow. It is not the authoritative source of the verification decision.

The decision is produced server-side after the checks run, and it reaches you by webhook. Never grant access based on the SDK's completion callback alone - a client-side signal is trivially forgeable, and the checks may not even be finished when it fires.

#One consumer app, or your own?

There is no separate consumer Didit app that a hosted session hands users off to for a step like NFC. If you want everything - NFC and non-NFC - inside a single app experience, that app is yours, with the SDK embedded in it.

#Distribution and dependency conflicts

Native SDK integration occasionally collides with other dependencies in a host app - a shared transitive library, or a subspec that pins a version something else also pins. If you hit one, it's a concrete, reproducible problem worth reporting with your dependency manifest rather than working around by pinning something old: the fix usually belongs in the SDK.

#Testing on a device

Sandbox works the same through an SDK as anywhere else - point the app at a sandbox application's key and every check is mocked and unbilled. That's the right way to rehearse a mobile flow, because the SDK behaviours you most need to test (permission prompts, camera lifecycle, backgrounding mid-capture) are device behaviours that cost you nothing to exercise repeatedly. See testing in sandbox.