A mobile app doesn't set a single browser cookie. There's no HTTP response header writing Set-Cookie, no cookie jar, nothing a browser DevTools panel would show you. That fact leads a lot of app developers to skip a cookie policy entirely, on the reasoning that the document is about cookies and the app has none. The reasoning is correct about cookies and wrong about the disclosure obligation, because the app almost certainly still assigns an advertising identifier, bundles SDKs that generate their own tracking IDs, and writes persistent values to local device storage, the exact functional equivalent of what a cookie does on the web, just implemented with different APIs. This guide covers what a mobile app's version of that document actually needs to name and how it differs from the privacy policy work most teams have already done.
Why "cookie policy" is still the right document, even without cookies
The law that created the cookie policy as a document, the EU's ePrivacy Directive, was never actually written around the word "cookie" as a technical term. Its consent requirement covers "the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user," language deliberately broad enough to reach any client-side storage or device-level identifier used the same way a cookie is, not just the specific mechanism browsers happen to call by that name. GDPR Article 5(3) and most national implementations carry the same "or similar technology" phrasing forward. A mobile app's advertising identifier and an SDK's locally stored install ID both fall inside that scope even though neither one is, technically, a cookie.
This is distinct from the ground covered in our guide to writing a privacy policy for a mobile app, which walks through the full data map: permissions, SDKs, and matching your policy to the App Store Privacy Nutrition Label and Google Play Data Safety form. That guide treats ad SDK data as one section inside a broader privacy policy. A standalone cookie or tracking policy is narrower on purpose, the same way it is on the web: it documents the specific tracking mechanisms, not the whole data-handling picture, and it's the document a cookie-style consent prompt or in-app tracking permission screen should actually link to.
The identifiers that do the job cookies do on the web
Four categories cover most of what a mobile app needs to disclose in place of cookies, and each maps to a rough web equivalent worth naming in the policy so a reader with any web experience understands what's actually happening.
Browser cookie concept vs mobile app equivalent
| On the web | In a mobile app | |
|---|---|---|
| Cross-site ad tracking | Third-party ad cookie | IDFA (iOS) or Google Ad ID (Android) |
| Analytics visitor ID | First-party analytics cookie | SDK install ID or app-instance ID |
| Session state | Session cookie | OS session token, in-memory or Keystore |
| Persistent local storage | localStorage / IndexedDB | UserDefaults or SharedPreferences |
| User consent to reset | Clear cookies in browser settings | Reset ad ID in settings, or ATT prompt |
The IDFA (Identifier for Advertisers) on iOS and the Google Advertising ID (GAID, sometimes still called AAID) on Android are the two that matter most, because they're the ones designed specifically for cross-app advertising and measurement, the closest functional relative to a third-party ad cookie. Both are reset by the user through device settings rather than a cookie-clearing button, and on iOS, access to the IDFA for tracking purposes requires an explicit App Tracking Transparency (ATT) prompt before your app or any SDK inside it can read it, a permission gate that has no direct browser-cookie parallel but serves the same consent function.
Below those two sit the identifiers most policies forget entirely: the ones your SDKs generate themselves. Firebase Analytics assigns its own app-instance ID independent of GAID. Attribution and marketing tools like AppsFlyer, Adjust, and Branch generate their own device or install identifiers to track where a user came from and what they did after installing. Crash reporting tools like Crashlytics or Sentry often attach a persistent device identifier to error reports so trends can be tracked across sessions from the same install. None of these are cookies. All of them persist across app opens, identify the same install or device over time, and exist for the same purpose a tracking cookie exists for on a website, which is exactly what makes them disclosable under the "similar technology" language rather than a narrower cookie-only reading of the law.
Mapping the consent flow before you write the disclosure
The practical difference between a web cookie banner and a mobile app's consent flow is that the mobile version is split across two separate gates that don't always fire together, and a policy written without tracing that flow first tends to describe a single, simplified prompt that doesn't match what actually happens on a device.
The takeaway from mapping this out is that "did the user consent" doesn't resolve to one yes or no per install. On iOS, it resolves per-ATT-prompt, and a denial doesn't turn off the SDKs, it just zeroes out the identifier they'd otherwise read, so your policy needs to describe what happens to analytics and attribution when that value is unavailable, not just what happens when it is. On Android there's no OS-level prompt equivalent to ATT at all, GAID is available by default and only genuinely gated if your own consent management flow (built for GDPR-scoped users, typically) blocks SDK initialization until the user answers a prompt you built yourself. Those are two different mechanisms producing two different disclosure obligations, and a single paragraph that says "we use advertising identifiers, subject to your consent" glosses over both without actually describing either.
What the policy itself needs to name
With the identifier map and consent flow traced, the document itself needs to cover, specifically rather than generically: which identifiers are used (IDFA, GAID, and each SDK's own generated ID, named individually rather than folded into "device identifiers"), which vendor reads each one and for what purpose (attribution, analytics, ad personalization, crash reporting), how long each identifier or its associated data persists, and how a user resets or opts out of each one, since the mechanism differs by identifier and platform rather than being one universal "clear cookies" action.
- We may use device identifiers and third-party SDKs for analytics and advertising.
- You can adjust your tracking preferences in your device settings.
- IDFA is read only if ATT consent is granted; AppsFlyer's install ID persists 90 days regardless.
- Reset GAID or IDFA in device Privacy settings; Firebase ID resets on app reinstall.
The specific version answers what a user asking "what is this app tracking about me, and how do I stop it" is actually asking. It also happens to be the same level of detail Apple's Privacy Nutrition Label and Google Play's Data Safety form already require you to have worked out, so a tracking policy built from that same source data stays consistent with what you've already declared to both stores rather than drifting into a separately maintained, looser description.
Where the app links this document matters too. On the web, a cookie policy is linked from the consent banner itself. In an app, the equivalent is a Settings or About screen, and ideally the ATT prompt's own pre-permission context if you're using one, since that's the moment a user is actually deciding whether to allow tracking and the moment they're most likely to look for more detail on what that means.
Building it from what you've already mapped
If you've already gone through the SDK and permission audit that a proper mobile app privacy policy requires, most of the source material for a standalone tracking policy already exists, it just needs to be reorganized around identifiers and consent mechanisms rather than data categories and legal bases. The question of whether that material belongs in one document or two follows the same logic covered in our guide on privacy policy vs cookie policy: a short, stable identifier list can live as a section inside the privacy policy, while an app running several attribution and ad SDKs with different reset mechanisms per platform benefits from a standalone, updatable page the ATT prompt and Settings screen can both link to directly.
Our Cookie Policy Generator builds that page from the specific identifiers, SDKs, and platforms you tell it about, so a mobile app's tracking disclosure names the actual IDs in use, IDFA, GAID, and the ones your analytics and attribution SDKs generate on their own, instead of a paragraph written for a website and stretched to cover a device it was never describing.
The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.
