Privacy & terms

Every iOS app needs a publicly reachable privacy policy URL before it can be submitted — and App Store Connect asks for it in several places. This flow makes it a two-minute job: you answer what the app actually does, and AppMate composes a clean privacy policy + terms from those facts.

This generates a document from facts you assert. It is not legal advice, and AppMate never infers what your app does — you state it.

The page is composed from structured answers, not a rich-text blob. That means it's correct by construction: a section appears only when the facts say it applies, and regenerating the page after you add or remove an SDK is trivial. Served at appmate.cloud/legal/{appSlug} (privacy) and /legal/{appSlug}/terms — a short, stable, crawlable URL with no redirect, no login, and no cookie banner, so a reviewer opens it directly.

How it works

State who owns the app (name + contact email), what data stays on the device, and which third-party services (processors) receive anything.
Toggle the platform capabilities the app uses (Health, location, notifications, iCloud, camera…) and the negative claims (we don't sell data / show ads / track…).
Publish. The effective date is stamped to today.

Known processors ship as presets

Name a service by id and its canonical description fills in — so the common case is naming revenuecat, not writing prose. Built-in: revenuecat, superwall, firebase, amplitude, posthog, sentry, mixpanel, appmate. Add a custom one with its own name + what it receives.

Only data that leaves the devicecounts as collection. Local storage, on-device HealthKit, and on-device location are described but are not “collected.” So an app that keeps everything local and uses RevenueCat correctly states that medication-style data never leaves the device, while still disclosing the anonymous id and receipt data RevenueCat receives — without you writing a sentence.

Immutable, dated versions

A privacy policy is a commitment with a date on it. Publishing freezes that version and archives the prior one; every published version stays addressable at /legal/{appSlug}/v/{n}, and the current page links to the history. Published pages are never silently rewritten.

App Store privacy declaration

The same structured config answers App Store Connect's App Privacy questionnaire. Get the derived nutrition label as JSON:

http

GET /legal/{appSlug}/app-store-privacy

[
  { "category": "Purchase History", "purpose": "App Functionality",
    "linkedToIdentity": false, "usedForTracking": false, "source": "RevenueCat" },
  …
]

Each entry names the processor that caused it. When nothing leaves the device you get dataNotCollected: true. This prevents a real, common mistake: declaring “Data Not Collected” while a purchases SDK is linked — a false declaration to Apple.

Owner (v1) API & MCP

GET /api/v1/apps/{idOrSlug}/flows/legal → config + public URLs
PUT /api/v1/apps/{idOrSlug}/flows/legal → full legal config (returns warnings)
POST /api/v1/apps/{idOrSlug}/flows/legal/publish → stamps the date, returns both URLs
GET /api/v1/apps/{idOrSlug}/legal/app-store-privacy → the derived declaration

The MCP server exposes get_legal_flow, update_legal_draft (with warnings on a missing contact email, an unknown processor, a cancel flow but no processors, or a future date), publish_legal_flow, and get_app_store_privacy_declaration — so an agent can spin up privacy + terms for a new app in one prompt.