Package-level declarations
The ready-made screens, their branding (WalletBrand, WalletBranding, CardFace) and the shared result screens (WalletResults, PresentmentResultOverlay).
The ready-made screens, their branding (WalletBrand, WalletBranding, CardFace) and the shared result screens (WalletResults, PresentmentResultOverlay).
Types
One face of a brand typeface: TTF/OTF bytes and the weight they represent.
Draws one credential type's card face (1024×646, ID-1 ratio). Apps register faces per doctype in WalletBranding.cardFaces (usually via WalletBrand); doctypes without one get the SDK's neutral face. The stored image is what the wallet, consent sheets and the iOS Digital Credentials sheet show.
The outcome shown on the one shared result surface, used by BOTH the wallet's presentment result and the verifier's verdict so they look like the same product. WARNING is the verifier's amber "authentic, but a check (revocation) could not be completed" state.
What a result screen shows: the animated badge, a title and an optional line under it.
Everything brand-specific about an app built on the SDK, in one place — so re-branding is one switch. Implement it once in your app (one object holding your brand) and call use at startup, before any wallet screen shows. The SDK itself stays brand-neutral.
The wallet UI's brand settings: the app's name, the brand typeface, each credential's card face and the app's own credential types. Apps normally set all of it at once with WalletBrand.use.
Presents over the W3C Digital Credentials API on Android: a browser calls navigator.credentials.get({ digital: … }), the user picks this wallet in the system sheet, and Credential Manager launches this activity. The SDK runs the exchange; this wires it to the wallet's store, branding and reader trust.
The ONE place that decides how every presentment outcome looks and reads — shared, cancelled, no matching card, identity check failed, error — on every path (in person, website, same device) and both platforms. Screens never spell out their own result text; they ask here.
Online presentment for a presentation request link — OpenID4VP by reference (openid4vp://, …) or ISO 18013-7 (mdoc://), e.g. a website's "share with wallet" button or a scanned QR (see com.wallet.ScannedCode). The SDK runs the flow (fetch + verify the request, consent, respond); this wires it to the wallet's store, branding and reader trust.
Properties
Functions
The one app title used across every screen and app — the Wallet home, the Verify reader, and any future reader (e.g. the Android NFC reader) — on both Android and iOS. Living in commonMain and being shared is exactly what keeps the top-left title identical everywhere. The connectivity state is a separate full-width ConnectivityBar pinned above this.
A slim full-width status line pinned at the very top of a screen (above the title), reading Offline (amber) or Online (green) from the device's real network state. Shared across the Wallet, the Verify reader and any future reader, on Android and iOS — so the operator always knows the mode, which matters here because revocation can only be established online (see the verifier's status row). Render it edge-to-edge, outside the content gutter.
Accept a scanned/deep-linked OpenID4VCI credential offer in one sheet over the wallet:
True if scanned is an OpenID4VCI credential offer (openid-credential-offer://…).
Full screen brightness (and no auto-lock) while in composition, restored on dispose — so a verifier's camera reads the engagement QR reliably.
First-run permissions without an extra step: on first open the system dialogs appear straight away, one after another (rememberSetupPermissionRequest: one combined request on Android, chained on iOS), over the app's own first screen — which doesn't change behind them. Most people just allow and carry on.
System back (Android back gesture/button) while enabled; a no-op on iOS, which has no system back.
The result glyph. APPROVED uses the exact Lottie "info was shared" success animation the SDK plays in the online presentment (so proximity and online look identical); CANCELLED = neutral slate ✕, ERROR = red ✕.
PresentmentResultContent for a ResultView from WalletResults.
The ONE result surface used across ALL presentment flows — offline proximity present and the online openid4vp:// share — so "shared", "cancelled" and "error" look identical everywhere. Renders a badge + title + detail and an optional action (e.g. a Done button). The caller supplies the container (a full-screen column, or a modal card over a scrim).
PresentmentResultOverlay for a ResultView from WalletResults.
The presentment result shown as a full-screen overlay (a dimmed scrim + a centred white card with the badge/animation), the same modal the wallet uses for "The info was shared". Tap anywhere to dismiss. Used by the verifier when a verification completes and by the wallet after a share, so the success animation pops as an overlay everywhere instead of being embedded in a page.
In-person (ISO 18013-5 QR + BLE) presentment, driven headlessly by the SDK's com.wallet.clients.WalletClient.startPresentment: Bluetooth gates → engagement QR for the verifier to scan → consent (the SDK's consent sheet, hosted by the app) → the shared result overlay: the same wording as the Android presentment screen: green "The info was shared", grey "Cancelled" (holder declined), red "Something went wrong" (or "None of your cards match this request").
Live connectivity via ConnectivityManager. Requires ACCESS_NETWORK_STATE (declared in each app's manifest). Reports online only when the active network has validated internet, so captive portals / "connected but no internet" read as offline.
Whether the device currently has usable internet, tracked live. Platform actuals use ConnectivityManager (Android) and NWPathMonitor (iOS). Defaults toward "offline" when the state can't be determined — honest for an offline-first proximity flow.
The wallet home's single action pill, split in two: SCAN (read a QR — credential offer or a verifier's request) and PRESENT (show an in-person engagement QR; the verifier's request picks which card is shared). Presenting isn't tied to a card, so it lives here rather than on each card.
Holder "Present in person" screen — offline ISO 18013-5 proximity over BLE.
Hosts the SDK's consent sheet (and passphrase prompt) for the wallet. Place it once, last, at the root of the wallet UI so it draws over every screen. The SDK's own screens (WalletViewController, WalletScreen) already host it.
Holder-side scan screen. The user scans either a verifier's request QR (e.g. a website's "share with wallet" code → presentment) or an issuer's credential offer QR (openid-credential-offer://… → add to wallet); onScanned fires once with the decoded string and the host routes it (see isCredentialOffer). Camera permission is asked for inside.
The wallet home: every credential the holder has, as a stack of cards. Tap a card to open it (it rises to the top and its fields are listed below it); tap it again to go back. Cards can be long-pressed and dragged to reorder, and the order is saved. Expired and revoked cards carry a badge.
The in-person verifier: pick a check, scan the holder's QR, read and verify the credential over Bluetooth (com.wallet.clients.VerifierClient), show the result. Built for staff checking IDs at a counter or a door: a clear valid / not valid banner, a large photo to compare with the person, the fields shared and the security checks. Works offline: issuers are checked against the trusted issuers your app configured (TrustedIssuers). Camera and Bluetooth permissions are handled inside.