# 移动端和 Web SDK

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

iOS、Android、React Native 和 Flutter 的原生 SDK 把流程嵌入你的应用，也是唯一支持 NFC 的方式；Web SDK 则嵌入你的前端。

原生 SDK 支持 **iOS、Android、React Native 和 Flutter**；Web SDK 则把流程嵌入你的前端。
当你需要 **NFC** 或最佳摄像头表现时，请使用原生 SDK，WebView 两者都无法提供。
结果仍然通过 webhook 返回，而不是来自 SDK 本身。

## 为什么用 SDK 而不是重定向

[Video: 完整集成指南 - Didit Academy](https://www.youtube.com/watch?v=fX03-WEu_EI)

托管重定向的工作量最小，对大多数流程来说也确实够用。
在以下情况下，SDK 是值得的：

- **你需要 NFC。** 护照或身份证中的芯片无法从浏览器页面读取。原生 SDK 是唯一的途径。参见 [NFC 芯片验证](https://help.didit.me/zh/documents-coverage/nfc-chip-verification)。
- **你不希望用户离开你的应用。** 在移动端，跳转出去再跳回来是一个真实的流失点。
- **你想要最佳的摄像头表现。** 原生摄像头访问比浏览器更可靠，尤其是在较旧的设备上。

## 有哪些可用

[Video: 选择合适的 Didit SDK - Didit Academy](https://www.youtube.com/watch?v=qHada8ZY24Q&t=14)

| 平台 | 说明 |
|---|---|
| **iOS** | 以 XCFramework 形式分发 |
| **Android** | 通过 Maven 分发 |
| **React Native** | 封装原生模块，支持新架构 |
| **Flutter** | 封装原生模块 |
| **JavaScript / Web** | 把托管流程嵌入你的 Web 前端 |
| **内嵌式 iframe** | 在你的页面内渲染流程，而不是重定向 |

![Didit 控制台中的集成页面，展示 SDK 和文档链接](https://help.didit.me/screenshots/integrate-light.webp)

*每个 SDK 都从与 API 相同的页面开始。*

iOS 支持 Swift Package Manager 和 CocoaPods；需要时在 `Info.plist` 中添加摄像头和 NFC 权限。Android 通过 Maven 分发。React Native 的 Expo 需使用包含原生模块的开发构建，不支持 Expo Go。

版本要求和平台最低支持会随发布变化，因此请查看最新的 [SDK 文档](https://docs.didit.me/integration/native-sdks/overview)，而不要依赖帮助页面里的旧信息。
如果你使用某个特定的框架版本（例如某个具体的 Expo SDK 版本），建议在投入一个冲刺周期之前，先与你的 Didit 联系人确认兼容性。

## WebView 不是原生 SDK

在 WebView 中包装托管的 Web 流程，看起来像是提供了应用内体验，但实际只是它的外观：

- **没有 NFC。** 芯片仍然无法读取。
- **摄像头权限更难处理。** WebView 的摄像头访问取决于宿主应用的配置，配置错误就会产生[修复活体检测与人脸比对问题](https://help.didit.me/zh/liveness-biometrics/liveness-and-face-match-issues)中提到的"摄像头始终无法打开"的报告。
- **语言跟随应用，而不是用户。** WebView 上报的是宿主应用的语言，因此需要在创建会话时显式传入 `language`。参见[设置验证语言](https://help.didit.me/zh/workflows/verification-languages)。

如果你愿意投入精力做应用内流程，就应该使用原生 SDK。

## 结果仍然来自 webhook

这一点常常让人意外：SDK 会告诉你的应用用户已经完成了流程，但它**不是**验证决策的权威来源。

决策是在检查运行结束后在服务端生成的，并通过 [webhook](https://help.didit.me/zh/integration/webhooks-basics) 送达。
永远不要仅凭 SDK 的完成回调就授予访问权限：客户端信号很容易被伪造，而且回调触发时检查甚至可能还没完成。

> **Warning:** 把"SDK 说完成了"当作"用户已通过验证"，是移动端集成中后果最严重的错误。
> 在解锁任何权限之前，请通过服务端、通过 webhook 或决策接口进行确认。

## 一个消费者应用，还是你自己的应用？

并不存在一个独立的 Didit 消费者应用，让托管会话把用户交给它去完成 NFC 之类的步骤。
如果你想要在一个应用体验中同时拥有 NFC 和非 NFC 的能力，那个应用就是**你自己的**，SDK 嵌入在其中。

## 分发和依赖冲突

原生 SDK 集成偶尔会与宿主应用中的其他依赖发生冲突，例如一个共享的传递依赖库，或者某个子模块锁定了另一个依赖也锁定的版本。
如果遇到这种情况，这是一个具体的、可复现的问题，值得连同你的依赖清单一起报告，而不是通过锁定旧版本来绕过它：修复通常应该在 SDK 一侧完成。

## 在设备上测试

通过应用名称下的切换器进入 **Sandbox**，创建并使用测试 API 密钥。所有检查都被模拟，不收费，你可以指定结果。

[在沙盒中测试](https://help.didit.me/zh/getting-started/sandbox-and-testing)