移动端和 Web SDK
iOS、Android、React Native 和 Flutter 的原生 SDK 把整个流程嵌入你的应用中，也是唯一支持 NFC 的方式。Web SDK 则把流程嵌入你的前端。
原生 SDK 支持 iOS、Android、React Native 和 Flutter；Web SDK 则把流程嵌入你的前端。 当你需要 NFC 或最佳摄像头表现时，请使用原生 SDK，WebView 两者都无法提供。 结果仍然通过 webhook 返回，而不是来自 SDK 本身。
#为什么用 SDK 而不是重定向
托管重定向的工作量最小，对大多数流程来说也确实够用。 在以下情况下，SDK 是值得的：
- 你需要 NFC。 护照或身份证中的芯片无法从浏览器页面读取。原生 SDK 是唯一的途径。参见 NFC 芯片验证。
- 你不希望用户离开你的应用。 在移动端，跳转出去再跳回来是一个真实的流失点。
- 你想要最佳的摄像头表现。 原生摄像头访问比浏览器更可靠，尤其是在较旧的设备上。
#有哪些可用
| 平台 | 说明 |
|---|---|
| iOS | 以 XCFramework 形式分发 |
| Android | 通过 Maven 分发 |
| React Native | 封装原生模块，支持新架构 |
| Flutter | 封装原生模块 |
| JavaScript / Web | 把托管流程嵌入你的 Web 前端 |
| 内嵌式 iframe | 在你的页面内渲染流程，而不是重定向 |
- 选择你的平台，页面会给出该技术栈对应的代码片段。
- 这里链接了原生和 Web SDK，各自附带独立的快速上手指南。
版本要求和平台最低支持会随发布变化，因此请查看最新的 SDK 文档，而不要依赖帮助页面里的旧信息。 如果你使用某个特定的框架版本（例如某个具体的 Expo SDK 版本），建议在投入一个冲刺周期之前，先与你的 Didit 联系人确认兼容性。
#WebView 不是原生 SDK
在 WebView 中包装托管的 Web 流程，看起来像是提供了应用内体验，但实际只是它的外观：
- 没有 NFC。 芯片仍然无法读取。
- 摄像头权限更难处理。 WebView 的摄像头访问取决于宿主应用的配置，配置错误就会产生修复活体检测与人脸比对问题中提到的"摄像头始终无法打开"的报告。
- 语言跟随应用，而不是用户。 WebView 上报的是宿主应用的语言，因此需要在创建会话时显式传入
language。参见设置验证语言。
如果你愿意投入精力做应用内流程，就应该使用原生 SDK。
#结果仍然来自 webhook
这一点常常让人意外：SDK 会告诉你的应用用户已经完成了流程，但它不是验证决策的权威来源。
决策是在检查运行结束后在服务端生成的，并通过 webhook 送达。 永远不要仅凭 SDK 的完成回调就授予访问权限：客户端信号很容易被伪造，而且回调触发时检查甚至可能还没完成。
把"SDK 说完成了"当作"用户已通过验证"，是移动端集成中后果最严重的错误。 在解锁任何权限之前，请通过服务端、通过 webhook 或决策接口进行确认。
#一个消费者应用，还是你自己的应用？
并不存在一个独立的 Didit 消费者应用，让托管会话把用户交给它去完成 NFC 之类的步骤。 如果你想要在一个应用体验中同时拥有 NFC 和非 NFC 的能力，那个应用就是你自己的，SDK 嵌入在其中。
#分发和依赖冲突
原生 SDK 集成偶尔会与宿主应用中的其他依赖发生冲突，例如一个共享的传递依赖库，或者某个子模块锁定了另一个依赖也锁定的版本。 如果遇到这种情况，这是一个具体的、可复现的问题，值得连同你的依赖清单一起报告，而不是通过锁定旧版本来绕过它：修复通常应该在 SDK 一侧完成。
#在设备上测试
沙盒在 SDK 中的表现与其他地方相同：把应用指向沙盒应用的密钥，所有检查都会被模拟且不产生费用。 这是排练移动端流程的正确方式，因为你最需要测试的 SDK 行为（权限弹窗、摄像头生命周期、采集过程中切到后台）都是设备行为，可以反复测试而不产生任何成本。 参见在沙盒中测试。