Prerequisites

Three things every consumer app needs before calling Octet.start(...):

1. A registered app so the SDK can bootstrap by attestation.
2. Privacy declarations in your app bundle (iOS Info.plist) or runtime permission grants (Android).
3. A minimum platform version.

1. Register your app

In 2.0 the SDK gets its license by proving the app's identity at first launch, not by carrying a key.

Sign up for an Octet account at sdk.octetproof.com/signup, then register your app identities at sdk.octetproof.com/apps. The link in your onboarding email lands there. In the Add an app identity dialog:

• iOS: your bundle id and Apple Team ID.
• Android: your package name and signing-certificate SHA-256. Use the dialog's separate Debug and Release certificate fields: a Debug cert registers a sandbox identity, a Release cert a production one. Avoid the single-certificate quick-register box on the signup page for Android, which writes one cert to both slots, so a debug build would take a paid production slot.

The first valid attestation from your app binds the identity to your account. A developer dashboard at dashboard.octetproof.com is on the way. /apps is the live surface today. See Attested bootstrap for how the handshake works.

iOS. Enable the App Attest capability for your app id. The SDK produces an App Attest attestation at first launch and an assertion on later launches.

Android. The SDK uses hardware key attestation: the device's TEE or StrongBox certificate chain is verified against Google's hardware-attestation root. No Google Cloud project is required. (The backend also checks Google's public keybox-revocation list to reject revoked devices, an unauthenticated fetch that needs no project or credentials.)

Local development, CI, and simulators. An emulator, a CI runner, and a locally built debug app have no hardware attestation. Use a sandbox bypass token. Register your Debug certificate under an app at /apps (the Debug field creates a sandbox identity), then mint a sandbox token for it there, choosing a 7-, 14-, 30-, or 90-day lifetime. It is revocable. Pass the token as OctetConfig.sandboxBypassToken. It looks like octet_sbx_…. A store or release build cannot use one: the SDK refuses a sandbox token outside a debug or simulator build, and the server refuses it for a production app.

The first 1,000 active users each month are free, and past that usage is billed at one US cent per active user, per month. An active user is a device that asked your app for at least one proof that month. The SDK reports a count per device, per month, and nothing else: no identity, no coordinates. A device that proves a thousand times counts once.

2. Platform privacy declarations

iOS: Info.plist keys

Add these to your app's Info.plist. Without them, the iOS runtime crashes on first launch with a privacy-sensitive-data error that names the missing key.

Required

<key>NSLocationWhenInUseUsageDescription</key>
<string>This app uses your location to verify and prove your location
to services that request it.</string>

<key>NSMotionUsageDescription</key>
<string>This app uses motion data to detect when you're stationary or
moving, which improves the confidence of location proofs.</string>

NSMotionUsageDescription is required. The SDK touches CMMotionActivityManager immediately during Octet.start(...), and Apple requires the usage description before any code accesses that API. Read-only access also counts.

The strings are user-facing. The copy above is a safe default. Rewrite in your product's voice if you prefer.

Required only if you enable background location

If your app needs proofs while backgrounded, also add:

<key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
<string>This app uses background location to continue generating
location proofs while you're not actively using it.</string>

<key>UIBackgroundModes</key>
<array>
    <string>location</string>
</array>

Without these the SDK silently falls back to foreground-only operation when the app is backgrounded. The SDK itself does not crash. Proofs stop generating until the app returns to foreground.

Android: runtime permissions

The SDK's AndroidManifest.xml declares the permissions the on-demand foreground proof flow uses: location, motion, foreground service, internet, and wake-lock. Manifest-merge propagates these into your app, so you do not copy them into your own manifest.

The SDK's manifest declares only the permissions the foreground proof flow uses, so ACCESS_BACKGROUND_LOCATION is not bundled. To generate proofs while the app is backgrounded, declare ACCESS_BACKGROUND_LOCATION in your own manifest.

You still request the runtime permissions from the user:

3. Minimum platform versions

Next: the iOS Quick Start or Android Quick Start.