Mobile SDK overview

The SenseCrypt Authenticator SDK embeds face authentication into your iOS or Android application. Your app gets a device-bound key in secure hardware, on-device face matching and liveness, and the same authentication flows the SenseCrypt Authenticator app uses — because that app is itself built on this SDK. The device key proves the device, and the live face match proves the person.

When to use the SDK

Use the SDK when you need the face ceremony to happen inside your own app, rather than handing the user off to the Authenticator app. Typical reasons:

• Your app is the authenticator for your product, and a second app is unacceptable UX.
• You are building a kiosk, field-service, or single-purpose device app where installing a separate authenticator isn't possible.
• You need to own the enrollment and sign-in screens end to end for branding or compliance reasons.
• Your users sign in to your app itself, and you want a face scan in the app, with no browser and no second app. That is in-app sign-in, for a tenant that runs its own app.

If none of those apply, integrate over OIDC/SAML instead — it is dramatically less work and carries no license, no native binaries, and no biometric surface in your app.

What the SDK gives you

• Device-bound keys. Key material is generated in the platform's secure hardware (Secure Enclave on iOS, Android Keystore on Android) and never leaves it. Every SDK call to SenseCrypt is signed with that key.
• On-device face matching and liveness. Detection, matching, and liveness run locally against models bundled in the SDK. No image and no biometric template leaves the device — SenseCrypt remains biometric-blind.
• Nine typed flows. Registration, login, in-app sign-in, face-PKI ceremonies, the passkey face report, the Android cross-device ceremony, key rotation, revocation, and face capture, each a state machine you observe rather than orchestrate.
• A passkey-provider surface. Everything a credential-provider extension or service needs except what only an app can own: publishing identities to the OS, signing the assertion offline, and the hand-off to the face report. See Passkeys and the face report.
• Optional drop-in UI. Ready-made QR-scan and face-capture surfaces (SwiftUI views, Compose composables) with camera handling, permission gating, and retry chrome already built. You can also drive the flows with your own UI.

Architecture

The SDK is a Rust core exposed to each platform through UniFFI bindings, with a hand-written idiomatic facade on top:

Your app  →  Swift / Kotlin facade  →  UniFFI bindings  →  Rust core
                                                            ├── flow state machines
                                                            ├── portal HTTP client (signed)
                                                            └── ML: detection, matching, liveness
             platform callbacks ────────────────────────────┘
             (Secure Enclave / Keystore, biometric prompt, secure storage, attestation)

Two consequences worth knowing up front:

The flows live in Rust, not in your app. You submit inputs (a QR payload, a PIN, a face capture) and observe emitted states. Retry budgets, signed aborts, network retries, and key ceremonies are all handled inside the core. This is deliberate — the security-critical sequencing is not something each host app should re-implement.

Platform-native concerns are injected callbacks. Key wrapping, secure storage, the biometric gate, and device attestation are implemented per platform and wired in by open(). You don't implement these; the SDK does it for you.

Platform support

The flows

Each flow except face capture is started from the SenseCryptAuthenticator handle; all emit a typed state and terminate in success, cancellation, or failure.

Getting started

Related

• Authenticator app — the end-user app, if you don't need to embed.
• Ship your own Authenticator app — registering your app with the tenant so the server verifies it.
• Relying party — integrating over OIDC/SAML with no SDK.
• How SenseCrypt works — the end-to-end model.
• Security — biometric blindness and key custody.