Product · SynOI Identity Mobile SDK

Roadmap

Verify a person, not a session.
Native on both platforms.

synoi-identity-mobileis a native Kotlin and Swift SDK for apps that are not the SynOI app: a dating app, a marketplace, or a Quest-style game that needs to confirm a user is who they claim to be, without standing up an identity system of its own. It is built on the SynOI Identity API's disclosure model: five preset bundles from L1 Discoverable to L5 Inner Circle, an NFC encounter chain for in-person taps, and on-device face match.

This is not SynOI Mobile (coming Q3 2026), the React Native shell that hosts downloadable SynOI modules on your own phone. This SDK is a library a third-party developer embeds directly in their own iOS or Android app, in Kotlin or Swift, so their users can disclose identity attributes to that app without SynOI running the app itself.

What's real today

Source and tests exist on both platforms. The server it calls does not, yet.

Equivalent Kotlin and Swift surface

A pure-JVM Kotlin core (testable without an Android emulator) plus an Android module with MLKit face detection and the Android NFC API, mirrored by a pure Swift package with Vision and CoreNFC wrappers.

Five disclosure presets

L1 Discoverable through L5 Inner Circle, each bundling which identity fields a counterparty sees. disclose() takes a counterparty and a preset.

Byte-identical encounter signing

The canonical signing bytes for an NFC encounter tap are required to match byte-for-byte between the Kotlin and Swift implementations, enforced by shared test vectors so a cross-platform tap between an Android and iOS device verifies the same way on both sides.

Pluggable capture providers

NFC capture and face-match inference happen through an NfcProvider / FaceMatchProvider you supply; postNfcTap and postFaceMatch take an already-built encounter half, they don't own the sensor code.

Not yet shipped

We would rather flag the gap than let a green build imply more than it does.

Every wire shape in this SDK, the disclosure request, the encounter chain, the receipt, is a provisional contract that has not been exercised against a running server: the Identity API backend does not exist yet. A passing test suite here is evidence the SDK code is internally consistent, not evidence that a real disclosure or verification flow works end to end.

Identity API server

Pending

The backend this SDK calls has not been built. No disclosure, NFC tap, or face-match call has an endpoint to reach today.

Selective disclosure (SD-JWT)

Pending

A field-level selective-disclosure profile is pinned in the docs, but there is no issuer, holder wallet, or verifier in this SDK yet: it is a target profile, not a working privacy system.

Signed, verifiable disclosure receipts

Pending

The disclosure receipt is modeled as a signed object aligned to the SynOI object format, but this SDK does not sign or verify anything itself.

Building the app that will need this?

Talk to us before the server ships. The wire contract is pinned; the sequencing of which apps go first is not.