Privacy & Compliance
Two separate Apple requirements get conflated constantly because both are about privacy and both showed up around the same time in the App Store's history: App Tracking Transparency, which governs cross-app tracking for advertising, and privacy manifests, which govern a specific technical category of API usage. They require different work, and missing either one can hold up a submission.
ATT governs "tracking" in Apple's specific sense: linking data collected in your app with data from other companies' apps or websites for advertising purposes, or sharing user or device data with a data broker. If your app does this — most commonly through an ad SDK using the device's advertising identifier (IDFA) — you must request permission through the AppTrackingTransparency framework before accessing the IDFA, using a system prompt whose accompanying explanation string (NSUserTrackingUsageDescription) you write yourself. Best practice is to ask at a moment where the value of allowing tracking is clear, rather than as the very first thing the app does, and the app must remain fully usable for its non-advertising functionality even if the user declines.
Separately, every app publishes a structured privacy disclosure in App Store Connect covering data categories — contact info, health, financial info, location, sensitive info, contacts, user content, browsing and search history, identifiers, purchases, usage data, and diagnostics. For each category you collected, you declare whether it's linked to the user's identity and whether it's used for tracking. This has to match actual behavior, including the behavior of every third-party SDK you ship — Apple has pulled apps post-launch over a mismatch between the declared label and observed data flows.
Since spring 2024, apps using certain "required reason APIs" — file timestamp APIs, UserDefaults, system boot time, and available disk space, among others — must declare, in a PrivacyInfo.xcprivacy file, why they use that API, from a fixed list of Apple-approved reasons. On top of that, many common third-party SDKs above a certain size threshold are now required to ship their own signed privacy manifest; if a dependency you use hasn't updated to include one, Apple will flag it, and eventually reject builds that include it. Checking your dependency list for privacy-manifest compliance is now a standard part of pre-submission review, not an edge case.
Google Play has its own structured disclosure — the Data safety section in Play Console — with a similar spirit to Apple's label, though a different form. Android's permission model is enforced at runtime rather than through a single declared string: dangerous permissions (camera, location, contacts, and so on) are requested individually when the feature is first used, scoped storage since Android 10 limits blanket file-system access, and POST_NOTIFICATIONS became its own runtime-requested permission starting with Android 13, rather than being granted automatically.
The consequences aren't hypothetical. A mismatched privacy label is grounds for rejection during review, and Apple has removed already-live apps after a later audit found a mismatch between the declared label and observed network behavior. A missing privacy manifest on a bundled SDK increasingly blocks submission outright rather than producing a warning. And beyond App Review entirely, inaccurate privacy disclosures can create real legal exposure under state and federal privacy law — this is compliance work with actual teeth, not a formality to get past a reviewer.
Timing matters operationally, too — both requirements have shown up as new obligations mid-lifecycle for existing apps, not just for new submissions. Treat privacy compliance as something you revisit at every release, especially any release that adds a new SDK, not as a box checked once at initial launch and forgotten.
None of this is exotic legal work — it's closer to a checklist that has to be run through deliberately, once per release, rather than assumed to still be accurate from the last time someone looked at it.
More from the journal
App Store
Apple rejects a meaningful share of first-time submissions, and it's rarely the exotic reasons founders worry about. Here's what actually trips people up, and how to submit clean.
Launch
Launch day is the easy part. The work that determines whether it goes well happens weeks earlier — here's the sequence we actually follow.
Engineering
Cross-platform frameworks have closed most of the historical gap with native — but not all of it. Here's the actual decision framework, not a philosophy war.