LivenessFacetecSDK para iOS, problemas comuns de build e dicas de diagnóstico.
Erros de inicialização — LivenessFacetecSDKInitError
Lançados por LivenessFacetecSDKClient.shared.initialize(config:):
O tipo conforma
LocalizedError — error.localizedDescription devolve uma mensagem legível.Erros de fluxo — LivenessFacetecSDKError
Emitidos como .error(LivenessFacetecSDKError) pelo AsyncStream de startLivenessCheck:
Não existem mais os casos
cancelled nem sessionError da v9: o cancelamento do usuário agora chega como .sessionNotCompleted, decidido inteiramente pelo status local da FaceTec — nunca por uma chamada de rede. Erros de criação de sessão ocorrem antes de startLivenessCheck e são tratados pelo consumidor.Status possíveis em sessionNotCompleted
O ClientStatus espelha o vocabulário de status compartilhado com a Web e declara 13 valores, mas o iOS produz apenas os 8 abaixo — 7 aqui, mais .sessionCompleted, que nunca chega em sessionNotCompleted por definição:
Os 5 casos restantes (
.rejectedByServer, .deviceNotSupported, .resourcesCouldNotBeLoadedOnLaser, .getUserMediaRemoteHttpNotSupported, .iframeNotAllowedWithoutPermission) nunca são emitidos no iOS — pertencem ao vocabulário da Web. Ainda assim, o compilador os exige num switch exaustivo sobre ClientStatus; trate-os com um default.Exemplo de tratamento
Problemas comuns de build
Crash em runtime ao iniciar a captura
OInfo.plist não declara NSCameraUsageDescription. O iOS termina o processo assim que o SDK tenta acessar a câmera.
Adicione:
Crash no device com erro de code signing
A build phase de re-assinatura está ausente, mal posicionada ou desatualizada. Confirme que ela aponta para osign-nested-frameworks.sh entregue com o artefato atual e roda depois do “Embed Frameworks” — veja Instalação.
a sealed resource is missing or invalid / crash com EXC_BREAKPOINT durante a sessão
O selo do LivenessFacetecSDK.framework está inconsistente. Isso acontece quando a build phase assina os frameworks aninhados sem re-assinar o container — o caso típico é uma cópia antiga do script colada dentro da build phase.
Substitua o conteúdo da fase pela chamada ao arquivo entregue pela Valid:
dyld: Library not loaded: @rpath/ShieldPtr.framework/ShieldPtr
O XCFramework não foi embutido com Embed & Sign, ou a build phase de re-assinatura está ausente. Confira os passos de instalação.
Erro de link library not found for -lLivenessFacetecSDK
O XCFramework não está sendo embarcado no target. Cheque em General → Frameworks, Libraries, and Embedded Content que o pacote está listado e marcado como Embed & Sign.
Erro de deployment target
alreadyInitialized em runtime
initialize() foi chamado enquanto o SDK já estava inicializado. Verifique LivenessFacetecSDKClient.shared.isInitialized antes de chamar. Para reinicializar, chame stop() primeiro.
facetecInitializationFailed em todo launch
Não é um problema de configuração do app consumidor: a inicialização foi rejeitada ou o provisionamento interno do SDK falhou. A mensagem devolvida é genérica e não distingue as duas causas — acione a equipe da Valid informando o Bundle Identifier do app.
.unknown("SDK not initialized. Call initialize() first.")
startLivenessCheck ou getSessionData foi chamado antes de initialize() completar com sucesso. Verifique isInitialized antes de iniciar o fluxo.
ssid vazio em getSessionData()
Não é um erro. A coleta de perimeter security é best-effort e pode devolver ssid vazio. Siga o fluxo normalmente — o backend aceita ssid vazio.
Loop for await não encerra após o resultado
O stream encerra sozinho depois de .success ou .error. Se o loop não termina, verifique se o Task que o envolve não está sendo cancelado prematuramente.
Limitação do simulador
Causa técnica: o XCFramework de produção fornecido pela FaceTec inclui, no slice de simulador (ios-arm64_x86_64-simulator), um binário stub — bem menor que a implementação real presente no slice ios-arm64. O stub compila e linka normalmente, mas nunca completa uma inicialização real de sessão.
O slice de simulador (fat binary arm64 + x86_64) existe apenas para permitir que apps consumidores compilem e vinculem ao SDK sem erros de build. O fluxo de liveness jamais é executado em simulador — qualquer tentativa falha por construção, não por bug.
Testes de fluxo completo de liveness devem ser realizados obrigatoriamente em dispositivo físico.
Privacidade e App Store
O XCFramework já embute o seu próprioPrivacyInfo.xcprivacy, e o ShieldPtr.framework aninhado traz o dele. A Apple agrega os dois automaticamente ao relatório do seu app — mas as declarações finais na App Store são responsabilidade do app consumidor.
Verificação de saúde
Use este checklist quando o SDK não inicializar:1
Confirme o XCFramework correto
Verifique se está usando
LivenessFacetecSDK-Release.xcframework (não uma variante de desenvolvimento ou um build anterior).2
Confirme conectividade
O dispositivo precisa alcançar os endpoints da Plataforma ID. Teste em uma rede sem proxy/firewall corporativo.
3
Valide os frameworks aninhados
Verifique se
LivenessFacetecSDK-Release.xcframework/ios-arm64/LivenessFacetecSDK.framework/Frameworks/ contém FaceTecSDK.framework e ShieldPtr.framework.4
Confirme a build phase de re-assinatura
A fase precisa apontar para
sign-nested-frameworks.sh e rodar depois do “Embed Frameworks”. Sem ela, qualquer instalação em device físico crasha logo no dlopen.5
Confirme NSCameraUsageDescription
A captura é abortada pelo iOS se essa chave não estiver no
Info.plist.6
Teste em dispositivo físico
O simulador nunca completa uma sessão real, por design do vendor.
Próximos passos
Implementação
Volte para a referência de uso do SDK
Customização
Veja como personalizar a UI do FaceTec