A
ATT system prompt
Probably not required
No IDFA access or code-level evidence of advertising, ad measurement, data-broker sharing, or cross-company identity joins.
Technical privacy assessment · 15 July 2026
Does Poe need Apple’s tracking prompt?
Probably not for the analytics implementation in this repo. Apple’s ATT prompt is for advertising-related cross-company tracking or access to IDFA—not for product analytics in general.
Codebase review + Apple policy research. This is a technical assessment, not legal advice.
01 · Executive view
Three questions, three different answers.
The common failure mode is treating Apple’s ATT prompt, the App Store privacy label, and ordinary privacy consent as one requirement. Apple treats them separately.
B
App Store privacy label
Likely must be updated
Product-interaction events are sent off-device and linked to the authenticated user ID. “Linked to You” is separate from “Used to Track You.”
C
Consent and governance
Not ready to close
The repo’s own release gate says legal/compliance sign-off, age and region rules, DPA status, withdrawal controls, and replay proof are unresolved.
The key distinction
Analytics is not automatically “tracking.”
Apple defines tracking around what happens across companies and why: targeted advertising, advertising measurement, or data broker sharing.
Understand how your own product is used
Feature usage, funnels, reliability, or audience measurement can be account-linked and still fall outside ATT.
Join data across companies for ads
ATT applies when app data is linked with other companies’ data for targeted advertising or ad measurement, shared with a data broker, or when IDFA is accessed.
02 · What the code says
The implementation is deliberately narrow.
The strongest evidence is not the word “analytics.” It is the actual data path: which identifiers exist, where data goes, which properties survive the relay, and which uses are enabled.
01
No ATT or advertising-ID code
The iOS target contains no NSUserTrackingUsageDescription, AppTrackingTransparency, AdSupport, IDFA, or IDFV reference, and the app target has no Swift package dependency that could hide one.
mobile/ios/Poe-iOS/Poe-iOS.xcodeproj/project.pbxproj · mobile/ios/Poe-iOS/Poe-iOS/Info.plistAgainst ATT
02
Analytics is off by default
POSTHOG_ENABLED and POSTHOG_REPLAY_ENABLED are false in the deployed configuration. An empty project key also makes the relay a no-op.
projects/poe-tiles/wrangler.toml:421–437Against current collection
03
First-party, same-origin relay
The browser posts to /__posthog/* on Poe’s origin. The server forwards only allowlisted paths and events, removes client headers and query strings, and replaces client identity with the authenticated Poe user ID.
packages/poe-tiles-api/src/api/posthog-relay/index.ts:260–278, 525–619, 747–782Against cross-company tracking
04
Ad and device context is stripped
The integration uses memory persistence, disables geo-IP, sends $ip: null, and removes URL, referrer, browser, OS, screen, device, email, phone, username, and display-name properties.
docs/posthog-analytics.md §1.6–1.9 · packages/analytics-client/src/analytics-mode.tsAgainst profiling
05
Account-linked product analytics remains
PostHog distinct_id is the authenticated session userId. Events describe product actions such as page views, app opens, invites, phone verification, first moves, and remix taps.
docs/posthog-analytics.md Status · §1.13 · §3Privacy label likely required
06
Replay is fail-closed
Production and preview replay eligibility returns false until consent, age, and region gating exists. The release checklist still blocks production enablement on privacy and payload proofs.
projects/poe-tiles/src/backend/posthog-replay-eligibility.ts:10–18 · docs/posthog-release-checklist.mdSeparate consent work remains
03 · The decision test
ATT turns on at a specific boundary.
Run every native SDK, webview script, SSO provider, attribution tool, and analytics vendor through these questions. One “yes” in the first three boxes changes the answer.
Access IDFA?
Yes → request ATT before access.
Join other-company data?
For ads or ad measurement? Yes → ATT.
Share with a data broker?
Yes → ATT, subject to narrow exceptions.
All no?
No ATT prompt. Continue the privacy-label and consent review.
04 · What could change the verdict
The answer is conditional, not permanent.
Apple holds the app responsible for code and vendors it includes. A same-origin relay and stripped device context are strong controls, but they do not replace a contractual answer about downstream use.
PostHog processor status is not evidenced in-repo
Before enablement, confirm the signed DPA and contract prohibit reuse of Poe event data for cross-customer advertising, ad measurement, audience building, or data-broker purposes.
The public privacy copy mentions advertising activity
The repo’s broader privacy page says Poe may collect advertising IDs and share hashed emails with advertising partners. No such implementation was found here, but adding it to this iOS app or its functional webview would require a fresh ATT analysis.
Session replay raises a separate consent bar
Replay is currently fail-closed in preview and production. Do not treat an ATT “no” as permission to turn replay on; close the repo’s masking, age, region, consent, retention, and access gates.
05 · Recommended next move
Ship clarity before shipping collection.
The repo already has strong technical controls. The remaining work is to align contracts, declarations, consent, and runtime evidence with those controls.
- 1Before App Review
Record a formal ATT decision
Document “no ATT” with the exact conditions: no IDFA, no ads/ad measurement join, no data-broker sharing, and PostHog acting only as Poe’s analytics processor.
- 2Before enablement
Close the vendor contract question
Confirm DPA execution, data-use restrictions, subprocessors, retention, deletion, and whether any optional warehouse or export integration could join other-company data for advertising.
- 3Before submission
Reconcile the App Store privacy label
Likely disclose Usage Data / Product Interaction for Analytics, linked to the user. Also review the APNs token as Device ID linked to the user for App Functionality. Mark “Used for Tracking” as no only after the vendor and advertising-use checks are closed.
- 4Before production
Finish consent and withdrawal design
Resolve age and jurisdiction rules, add an understandable way to withdraw ordinary analytics consent where required, and keep replay independently gated.
- 5Release evidence
Add the privacy manifest, then verify the built app
Declare the native UserDefaults required reason, inspect Xcode’s privacy report and embedded SDK manifests, then inspect live traffic with analytics enabled. Test a denied ATT state to prove no tracking-domain or advertising-ID path is attempted.
If the answer ever becomes “yes”
Then add the system prompt—carefully.
Add NSUserTrackingUsageDescription, request permission before any tracking or IDFA access, and write a brief, specific purpose string. Ask in context. Do not gate app functionality, incentivize consent, mimic the system alert, or steer users toward Allow.
06 · Primary sources
Read the policy behind the verdict.
Apple’s definitions and the codebase are the primary evidence. Policy can change; re-run this review before a materially different analytics, advertising, identity, SSO, or attribution launch.