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.

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.

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.
• Five typed flows. Registration, login, key rotation, revocation, and face capture, each a state machine you observe rather than orchestrate.
• 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 five flows

Each flow is started from the SenseCryptAuthenticator handle, emits a typed state enum, and terminates in success, cancellation, or failure.

Getting started

Related

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