Rooms, north
and device evidence.

Install the published packages

Swift 1.3.1 · API client and RoomPlan module

Swift 1.3.1 exports VedikaSDK and VedikaRoomCapture. Add the products your app uses:

.package(url: "https://github.com/vedika-io/vedika-sdk-swift.git", exact: "1.3.1")
// In your target dependencies:
.product(name: "VedikaSDK", package: "vedika-sdk-swift"),
.product(name: "VedikaRoomCapture", package: "vedika-sdk-swift")

The room module includes RoomCaptureScanView, CaptureOutbox, OverlayRelocalizationGate and LocalWorldMapStore. Published symbols are verified; a fresh iOS consumer build, complete encrypted-outbox tests and real-phone measurements are separate pending gates.

Android · API client 1.1.0 and AR module 1.0.2

Use the published Android client and Android AR module from JitPack:

// In dependencyResolutionManagement.repositories:
maven { url = uri("https://jitpack.io") }
// In your app dependencies:
implementation("com.github.vedika-io:vedika-sdk-android:1.1.0")
implementation("com.github.vedika-io:vedika-sdk-android-ar:1.0.2")

The AR artifact contains VastuArCoreCaptureView. Android 1.0.2 does not export CaptureOutbox, AndroidCaptureStore or LocalOverlayRelocalizer; do not integrate those source-only features as published APIs. Fresh application compilation and real-phone scanning remain unverified.

The browser AR room scan is Android Chrome only. Native iPhone and Android scanning is not yet accepted as a measured physical capability.

Capture and review

The Swift package adds VedikaRoomCapture. RoomCaptureScanView wraps the platform scanner with coaching, a room-type picker, explicit north confirmation and perimeter review. A LiDAR device runs RoomPlan. The simulator replays generated room JSON; it does not scan.

Pair calibrated magnetic compass samples with current camera poses. Fetch direction/declination using a recent location, show its correction and ask the person to confirm north. The adapter applies that correction once, exports metres with east/north axes, chains walls into the outline, and preserves door/window dimensions. No magnetic reading is silently called true north.

CapturedStructure needs labels for every room and a separately traced property boundary in its shared coordinate frame. RoomPlan section suggestions do not establish the room's use. Device JSON exports stay private; the committed fixtures are synthetic 4 × 5 m living and 3 × 4 m kitchen rooms.

Offline capture

Swift 1.3.1 includes CaptureOutbox: keep one outbox owner per store. Its source uses a Keychain key and AES-GCM snapshots for property references, request IDs, idempotency IDs and retry checkpoints. Key loss fails closed. These source properties await the Apple encrypted-outbox test gate. The Android encrypted queue is implementation preparation, absent from the published 1.0.2 AR artifact; offline retry is not a shipped Android capability.

The Swift outbox contract defines unsynced, synced or failed entries. Resume sends the same JSON body and idempotency key after connectivity returns or the app restarts. Backoff is persisted before the request. This resumes an atomic JSON request, not a multipart transfer. HTTP 409 remains failed unless a trusted server readback establishes the same ID and body hash. A successful idempotent replay uses the normal success envelope.

Reuse overlays only after relocalization

The published Swift source includes LocalWorldMapStore to save an encrypted ARWorldMap and puts its local filename, plaintext hash and anchor IDs in the encrypted property-capture sidecar. The public capture schema stays unchanged. Restore verifies the hash and anchors. A gate checks normal tracking and current physical-landmark reprojection agreement for three consecutive frames; tracking loss or an error immediately hides overlays. The default 8-pixel tolerance is a policy threshold, not a measured accuracy promise.

Android source preparation uses local anchors with Cloud Anchors and Geospatial disabled; its queue and relocalization helpers are not exported by the published 1.0.2 artifact. Anchors belong to one ARCore session. There is no persistent Android world map or cross-session overlay restoration here: after an app restart, rescan and establish new landmarks. The prepared overlay render callback is gated per frame; this is not a published Android overlay guarantee. Observations must be fresh marker detections or taps on physical landmarks, never saved screen pixels.

Device matrix

Historical iOS simulator evidence is dated 3 October 2026 and does not prove the newly published 1.3.1 consumer. Capability gates below describe supported platform interfaces; current physical cells are deliberately unfilled.

iOS exposes CLHeading.headingAccuracy in degrees; negative means uncalibrated. Android's sensor accuracy is an ordinal status, not an angular error. Do not report that ordinal as degrees. Actual heading and position errors need an independent reference.

Run on real devices

1. Record device model, OS, mode and a unique trial ID. Survey a true-north reference and measure landmark coordinates independently.
2. Run at least ten complete attempts per mode. Include failed attempts. For iOS, test LiDAR and non-LiDAR; for Android, test depth and depth-unavailable modes. Exercise offline enqueue, restart, online retry and tracking-loss overlay refusal.
3. Record heading pairs, position pairs and compass accuracy only when observed. Leave absent values blank. Keep raw captures private.
4. Run the repository harness. It computes circular heading error, Euclidean position error and completion rate from supplied trials, and preserves missing measurements.

python3 tests/vastu-lab/top25/native_device_harness.py trials.csv \
  --template --output measurements.json
# Fill trials.csv with actual observations, then:
python3 tests/vastu-lab/top25/native_device_harness.py trials.csv \
  --output measurements.json

Register your application

Attestation verifies application/device proof; capture geometry remains caller-reported. The simulator cannot prove App Attest or production Play Integrity. Register your own app with Vedika before testing on a physical device.

iOS · App Attest

1. Use your Apple Team ID and bundle ID. Enable App Attest capability, set the production entitlement for release, and keep development and production enrollment separate.
2. Provide Vedika the Team ID, bundle ID and environment through the authenticated integrator registration process. No shared Vedika identity is embedded in the SDK.
3. Persist the generated key ID in your Keychain. Request ar/attestation/challenge for ios. A null challenge means not configured: surface it, never invent a proof.
4. Use AppAttestCaptureProof.proof. First enrollment sends attestationObject; subsequent requests send assertion. Mark the key enrolled only after server verification. Losing a key requires enrollment again.

Android · Play Integrity

1. Register your package name, Play signing certificate SHA-256 and integrity project with your own account. Give Vedika only the approved secret reference and identifiers through authenticated registration; never place service-account JSON in an app or repository.
2. Prepare your Standard Integrity token provider. Fetch a single-use android challenge and pass the helper's hash to StandardIntegrityTokenRequest.setRequestHash. Supply the returned token to the proof adapter.
3. Keep operation and body unchanged after binding. Challenges expire after five minutes. Refresh challenge/proof after expiry while retaining the queued body and billing ID.

Binding is SHA-256 over vedika-attest-v1\noperation\nchallenge\ncanonicalJson(body without deviceAttestation). Apple receives the raw 32-byte digest; Play receives unpadded base64url. The Swift and Kotlin helpers test the repository's shared vectors.

See Apple App Attest, Standard Play Integrity, ARCore anchor scope and Tink setup.