SDK overview

The Folio SDK brings Folio identity verification and the encrypted Folio vault into your own iOS, Android and web apps. One shared core holds all business logic. Each platform gets a native package on top of it with an interface in that platform's language: Swift on iOS, Kotlin on Android and TypeScript on the web. Because every package runs the same core, a feature behaves the same way on every platform.

How your app works with the SDKCopy Anchor Link

Your app never calls the SDK to fetch data. It works with stores:

1. It creates one runtime object, FolioSdk, when it starts.
2. It mounts the stores it needs on that runtime.
3. It renders the state a store publishes. The state is already shaped for the screen.
4. It sends an action to the store for every user interaction. The result arrives as a new state.

All decisions, such as which request to send, how to retry or which screen comes next, stay inside the SDK. Runtime and stores describes the object and the store contract in detail.

The runtime objectCopy Anchor Link

FolioSdk is the single entry point. You create it once with FolioSdk.create(config, mapper), an asynchronous call on every platform:

• config is a FolioSdkConfig: the Folio base URL, your organization, an optional development configuration and logging writers. Your app's identity comes from the platform. See Configuration.
• mapper is your IdentityRecordMapper. It turns a verified identity into the record the SDK saves in the vault. See Identity records.

create restores the stored session, or starts a new one, before it returns. The runtime itself returns no data: it orchestrates, and the stores own data access. Close the runtime when your app no longer needs it: close() is asynchronous on every platform and shuts the runtime down before it releases it.

Each platform also has a provider, FolioSDKProvider, that hands the runtime to your views: a SwiftUI view on iOS, a composable on Android and a React component on the web. See Runtime and stores.

The storesCopy Anchor Link

The runtime hosts eight stores. Each one is mounted on the runtime, publishes one state type and accepts one action type. A store exposes its current state as a property, and subscribe() returns a subscription that yields the current state first and then the latest state after each change.

Ready-made verification UICopy Anchor Link

You do not have to build the verification screens yourself. Each package ships a ready-made inquiry UI that runs on a mounted InquiryStore:

• iOS: the SwiftUI view FolioInquiry in the FolioInquiryUI product.
• Android: FolioInquiry.open, FolioInquiry.Host (Compose) and FolioInquiry.present (own activity) in id.folio.sdk.inquiry.
• Web: the React component FolioInquiry from @folio/sdk/inquiry.

See Inquiry UI. A web page that does not run the SDK itself can load the inquiry through a script tag instead; see Inquiry embed. The selfie step runs a liveness engine that each package brings with it; see Selfie capture.

One package per platformCopy Anchor Link

The type names are the same on every platform, such as FolioSdk, InquiryStore and InquiryUiModel. The error type of a failed SDK call differs: FolioSDKError in Swift and TypeScript, FolioSDKException in Kotlin. Platforms lists the supported platform versions.

Where to go nextCopy Anchor Link