# SDKs móveis e web

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

Os SDKs nativos para iOS, Android, React Native e Flutter põem o fluxo dentro da tua aplicação e são o único caminho com NFC. Os SDKs web incorporam-no.

Existem SDKs nativos para **iOS, Android, React Native e Flutter**; os SDKs web
incorporam o fluxo no teu frontend. Usa um SDK nativo quando precisares de
**NFC** ou do melhor comportamento de câmara - uma WebView não te dá nenhum
dos dois. Os resultados continuam a chegar por webhook, não pelo SDK.

## Porquê um SDK em vez de um redirecionamento

[Video: O guia completo de integração - Didit Academy](https://www.youtube.com/watch?v=fX03-WEu_EI)

Um redirecionamento alojado é o que dá menos trabalho e é genuinamente adequado para a maioria dos fluxos. Um SDK vale a pena quando:

- **Precisas de NFC.** O chip de um passaporte ou cartão de identificação não pode ser lido a partir de uma página de navegador. Um SDK nativo é o único caminho. Consulta [verificação de chip NFC](https://help.didit.me/pt-PT/documents-coverage/nfc-chip-verification).
- **Não queres que o utilizador saia da tua aplicação.** Um redirecionamento para fora e de volta é um verdadeiro ponto de abandono no telemóvel.
- **Queres o melhor comportamento de câmara.** O acesso nativo à câmara é mais fiável do que o de um navegador, especialmente em dispositivos mais antigos.

## O que está disponível

[Video: Escolher o SDK do Didit certo - Didit Academy](https://www.youtube.com/watch?v=qHada8ZY24Q&t=14)

| Plataforma | Notas |
|---|---|
| **iOS** | Distribuído como XCFramework |
| **Android** | Distribuído via Maven |
| **React Native** | Envolve os módulos nativos; suporta a New Architecture |
| **Flutter** | Envolve os módulos nativos |
| **JavaScript / web** | Incorpora o fluxo alojado no teu frontend web |
| **Iframe in-context** | Renderiza o fluxo dentro da tua página em vez de redirecionar |

![A página Integrate na consola Didit com os links de SDK e documentação](https://help.didit.me/screenshots/integrate-light.webp)

*Todos os SDKs partem da mesma página que a API.*

iOS disponibiliza Swift Package Manager e CocoaPods; adicione permissões de câmara e NFC ao `Info.plist` quando necessário. Android usa Maven. React Native suporta Expo através de uma compilação de desenvolvimento com módulos nativos, não através de Expo Go.

Os requisitos de versão e os mínimos de plataforma mudam com os lançamentos, por isso consulta a [documentação atual do SDK](https://docs.didit.me/integration/native-sdks/overview) em vez de uma captura de uma página de ajuda - e se estiveres numa versão de framework específica (um determinado SDK do Expo, por exemplo), confirma a compatibilidade com o teu contacto na Didit antes de te comprometeres com ela num sprint.

## Uma WebView não é um SDK nativo

Envolver o fluxo web alojado numa WebView parece dar-te uma experiência dentro da aplicação. Dá-te a aparência de uma:

- **Sem NFC.** O chip continua a não poder ser lido.
- **As permissões de câmara são mais difíceis.** O acesso à câmara de uma WebView depende da configuração da aplicação anfitriã, e configurá-lo mal produz exatamente os relatos de "a câmara nunca abriu" cobertos em [corrigir problemas de prova de vida e correspondência facial](https://help.didit.me/pt-PT/liveness-biometrics/liveness-and-face-match-issues).
- **O idioma é o da aplicação, não o do utilizador.** Uma WebView reporta o idioma da aplicação anfitriã, por isso passa `language` explicitamente ao criar a sessão. Consulta [definir o idioma da verificação](https://help.didit.me/pt-PT/workflows/verification-languages).

Se vais ao trabalho de criar um fluxo dentro da aplicação, usa o SDK nativo.

## Os resultados continuam a vir dos webhooks

Isto apanha muita gente desprevenida: o SDK diz à tua aplicação que o utilizador terminou o fluxo. **Não** é a fonte autoritativa da decisão de verificação.

A decisão é produzida no lado do servidor depois de as comprovações correrem, e chega até ti por [webhook](https://help.didit.me/pt-PT/integration/webhooks-basics). Nunca concedas acesso apenas com base no callback de conclusão do SDK - um sinal do lado do cliente é trivialmente falsificável, e as comprovações podem nem sequer ter terminado quando ele dispara.

> **Warning:** Tratar "o SDK disse que terminou" como "o utilizador está verificado" é o erro
> mais consequente possível numa integração móvel. Confirma no teu servidor, a
> partir do webhook ou do endpoint de decisão, antes de desbloqueares seja o
> que for.

## Uma aplicação de consumidor única, ou a tua própria?

Não existe uma aplicação Didit de consumidor separada para a qual uma sessão alojada encaminhe os utilizadores para um passo como o NFC. Se quiseres tudo - NFC e não-NFC - dentro de uma única experiência de aplicação, essa aplicação é a **tua**, com o SDK incorporado nela.

## Distribuição e conflitos de dependências

A integração de um SDK nativo colide ocasionalmente com outras dependências numa aplicação anfitriã - uma biblioteca transitiva partilhada, ou uma subspec que fixa uma versão que outra coisa também fixa. Se encontrares um caso destes, é um problema concreto e reproduzível que vale a pena reportar com o teu manifesto de dependências, em vez de contornar fixando algo antigo: a correção normalmente pertence ao SDK.

## Testar num dispositivo

Mude para **Sandbox** no seletor abaixo do nome da aplicação, crie uma chave de API de teste e utilize-a. As verificações são simuladas, sem faturação, e pode escolher o resultado.

[testar em sandbox](https://help.didit.me/pt-PT/getting-started/sandbox-and-testing)