Blog

Consent in native apps: one record for web and mobile

Published on

A user who declines marketing on your website and opens your app shouldn't be asked again — or worse, tracked anyway. What changes when consent moves from the browser to iOS and Android, and what doesn't.

Most consent setups were built for the browser: a banner, a cookie holding the choice, scripts that wait for it. Then the company ships an app, and consent gets rebuilt from scratch — a second set of toggles, a second storage location, a second answer to "what did this person agree to?" The two drift apart within weeks.

The fix isn't a better mobile banner. It's one record per person, written by whichever surface they happen to be using.

Same contract, different runtime

The iOS, Android and Flutter SDKs mirror the JavaScript SDK method for method: getPurposes for the exact published wording, recordConsent to write a decision, getConsentState to read it and gate() to hold back an SDK — an analytics or attribution library — until the matching purpose is granted. A decision recorded in the app lands in the same vault, under the same subject, as one recorded on the web.

What actually changes in an app

  • There's no Origin header. Browser keys are protected by an allowlist of domains; an app can't present one. The app's pk_ key needs Allow native apps enabled, otherwise every call returns 403. That setting is per key, so your web key keeps its Origin check.
  • The key ships in the binary. Anyone can extract it. That's why only pk_ keys go in an app — never sk_ — and why a pk_ key on its own can only reach anonymous device identifiers.
  • Signed-in users need an identity token. To read or write consent for email:… or your own user id, the app passes a short-lived token your backend signs — so an extracted key can't be used to look up someone else's choices. See identifying logged-in users.
  • Anonymous → signed in is a merge. Choices made on a device before login carry over to the account; nothing is asked twice. See anonymous → identified.

Proof works offline, on the device

Each decision comes back with an Ed25519-signed receipt. The native SDKs verify it on-device — CryptoKit on Apple platforms, Google Tink on Android — against the public keys at /.well-known/jwks.json. The app can show a user their own consent history and prove each entry is authentic without trusting the network path it came over. More in what a signed receipt actually proves.

Where it stands today

The mobile SDKs are in early access: source-complete and tested, ahead of publication to SPM, Maven Central and pub.dev. If you're planning an app release that needs consent, talk to us and we'll set you up — and in the meantime the same flows are available directly over the REST API, which is what the SDKs call underneath.