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.
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 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).