Screenshots

Every screenshot on this page was captured from the reference applications at the same source revision on a standing test device or in the browser loop. Provider credentials were supplied at runtime through each app’s settings surface or its documented automation seam; no build on this page embeds a credential.

Android — Kotlin and Jetpack Compose

The Android reference application drawing downtown Sacramento, with the readiness chip, map controls, scale bar, the compact attribution info control at the map’s end edge and the search dock

iOS — Swift and SwiftUI

The iOS reference application drawing downtown Sacramento, with the readiness chip, settings control, map controls, scale bar, the compact attribution info control at the map’s end edge and the plan dock

WebAssembly — the browser playground

The wasm playground rendering the same Sacramento camera on a WebGPU canvas, with the Plan a trip card, the map controls and the compact attribution info control at the end edge

The browser build runs the SDK’s own wasm module and draws through WebGPU, so the playground is the same core rather than a simulation. The capture shows its consumer surface: Plan a trip with a selected demo destination, with the expert controls folded under Advanced. It is served keyless at the live demo over the committed fixture imagery.

React Native — one TypeScript surface, two native shells

The React Native reference application rendering downtown Sacramento inside the shared JS shell, with the readiness chip, map controls and the search dock

Reading the screenshots

The four captures share one camera, one design language (the reference-app UX tokens) and one demo artifact. Differences are the platform’s own chrome: Compose’s Material surface on Android, SwiftUI’s safe-area handling on iOS, the React Native bridge’s host view, and the browser’s WebGPU canvas. The map content, the control cluster, the scale ladder and the attribution line are the same.