> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tappify.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Privacy & security

> What the Tappify SDK collects, who can see it, and where it lives — written to be shared with your security team.

This page describes the Tappify SDK's data behavior end to end. It's written to be pasted
directly into a security questionnaire.

## Inert until paired

The SDK ships dormant. Before a device on your app has been through an explicit pairing —
someone on your team scanning a QR code or opening an activation link from the Tappify
dashboard — the SDK makes **no network calls, renders no UI, and collects nothing**. The one
narrow exception: on internal (TestFlight/development) builds only, if your app's gating
mode allows internal review, the SDK may make a single anonymous call to learn whether to
show a "Sign in with Tappify" affordance — that call returns nothing but a gating setting,
no thread data, no org data, no personal data. On builds downloaded from the App Store, even
that exception doesn't apply: nothing happens before pairing, full stop.

There is no code path by which the SDK collects data, calls out over the network, or
displays anything to a user who hasn't been through pairing.

## What end users can ever see

Nothing. Review mode is invisible to your app's end users by construction, not by
configuration. A device only sees the overlay after someone on your team explicitly pairs
it, and pairing is only ever initiated from your Tappify dashboard by an authenticated
member of your organization. The overlay is **inert unless a paired org member is
present** — there's no way for an end user to discover, trigger, or interact with it. An
app's end users, and Tappify users outside your organization, cannot detect that the SDK is
present in your app at all.

## What is collected, and when

Data collection only ever happens after pairing, and only as a direct result of a reviewer's
own actions:

* **Screenshots** — taken deliberately, when a paired reviewer taps the pill to start a
  comment. The SDK never captures a screen automatically or in the background; a screenshot
  only exists because a reviewer chose to leave a comment on that screen at that moment.
* **Comment text** — whatever a reviewer types into the composer.
* **Device and build metadata** — attached to each comment thread, for context: app version
  and build number, OS version, device model, device locale (language/region identifier),
  and the SDK's own version string. This is the same category of information any
  crash-reporting or analytics SDK collects, scoped to giving reviewers and your team enough
  context to know what a comment refers to.

None of this is collected from, or about, your app's end users — only from devices that a
member of your organization has explicitly paired for review.

## Access control

Visibility into review threads, screenshots, and device lists is enforced **server-side**,
re-checked on every activation and on every ongoing session check — never left to the client
to decide. A device can only see and post comments for apps owned by the organization that
paired it; membership in one organization never grants visibility into another organization's
apps, even when both organizations' apps are built by the same team or signing identity (see
[Team-wide pairing](/sdk/team-wide-pairing) for the case where that distinction matters
most). Revoking a device removes its access on its next check-in.

## Where data lives

Screenshots are stored in S3. Comment text, thread metadata, and device records are stored
in Tappify's backend database. Nothing collected by the SDK is stored on-device beyond what's
needed to maintain the current paired session.

## Privacy manifest

The SDK ships an Apple privacy manifest (`PrivacyInfo.xcprivacy`) declaring exactly what it
collects, consistent with everything on this page:

* **Tracking:** none. No tracking domains are declared.
* **Collected data types:** "Other user content" (comment threads and screenshots) and
  "Other diagnostic data" (device/build metadata), both declared for **app functionality**
  only — not analytics, not advertising, not tracking.
* **Accessed API categories:** `UserDefaults`, used only for the SDK's internal crash-safety
  bookkeeping (detecting whether the SDK completed its last run cleanly).

These declarations describe what's collected **after pairing** — consistent with the rest of
this page, nothing is collected before it.