Guide

Privacy-first iOS analytics

"Privacy-first" is a claim anyone can print on a landing page. This is the checkable version: what Apple actually enforces, what GDPR actually requires, and the questions that separate an analytics SDK that respects your users from one that only says so.

Short answer

Analytics that stays inside your own app is not tracking in Apple's sense, so it needs no ATT prompt. If it also collects nothing personal, there is very little for a consent banner to ask about.

What decides all of this is one thing: which identifier represents a user, and where it came from. Everything else on this page follows from that. Jump to the ten questions to ask a vendor if you want the short version.

We make one of these tools, so we have a horse in this race. Everything below about Apple's and the GDPR's rules can be checked independently, and you should check it. This is a developer's summary, not legal advice. Written August 2026, and it applies to Android too: Google Play's Data safety form asks nearly the same questions in different words.

What Apple means by "tracking", which is narrower than you think

Most of the confusion in this area comes from one word. In Apple's vocabulary, tracking does not mean "collecting data about users". It means one of exactly two things.

This is tracking prompt required

Joining your data with other companies' dataYour app's data gets matched up with what other companies collected in their apps or websites, so that ads can be targeted or measured.

Handing data to a data brokerSharing user or device data with a company whose business is selling it on.

FingerprintingWorking out a stable identity from device signals such as model, locale, screen size or installed fonts. Apple counts this as tracking and does not allow it even with permission.

This is not tracking no prompt

Counting what happens in your own appSessions, screens, installs, the events you name yourself.

Keeping it to yourselfNever joined with anyone else's data, never sold, never used for ads.

Even if you know who the user isAttaching your own customer's email to your own analytics is "linked", which is a separate question. It is still not tracking.

This is why a well-built analytics SDK needs no App Tracking Transparency prompt, and why the "Data Used to Track You" section of its privacy label reads None.

✓ The rule of thumb.

If the data never leaves your control, and is never joined to another company's data for advertising, you are not tracking, and there is no ATT prompt. The moment an ad SDK, an attribution network, or an audience-sharing integration enters the app, that answer flips for the whole app, not just for that SDK.

The ATT prompt: when you genuinely need it

You have to call ATTrackingManager.requestTrackingAuthorization before touching the advertising identifier, or otherwise tracking. In practice that means you run ads with attribution, you use an ad network's SDK, you share data for audience building, or you fingerprint devices.

The prompt is also expensive. Opt-in rates are low, and the prompt itself costs you trust and screen space at the worst possible moment. Not needing it is a feature, not a technicality.

App Privacy labels: three boxes, one honest answer

Every app answers the App Privacy questionnaire in App Store Connect, and the result shows up on your store page in three boxes: Data Used to Track You, Data Linked to You, and Data Not Linked to You. Privacy-first analytics should put you entirely in the third one, with two rows:

Identifiers, then User ID. A random id made up for that install, not the advertising identifier.
Usage Data, then Product Interaction. Sessions, screens, the events you track.

Purpose: Analytics. Linked to identity: No. Used for tracking: No. That is a two-line label, and it stays two lines unless you deliberately attach an identity. Generate yours with the free tool, including the Google Play answers →

The cookie banners you see on the web come from the ePrivacy Directive's rule about storing or reading information on someone's device, plus the GDPR's requirement of a lawful basis for processing personal data. Two things follow for an app:

If your analytics collects no personal data, meaning no name, email, account id, ad identifier, IP-derived location, or identity shared across services, there is far less to consent to, and the common industry reading is that a banner is not required for it.
If you attach an identity, such as an email or your own account id, you are processing personal data. You need a lawful basis, a line in your privacy policy, and a way to honour deletion requests.

⚠️ Careful with certainty here.

Regulators differ, an identifier stored on the device can itself be in scope, and your obligations depend on what your whole app does, not just its analytics. Anyone who tells you "definitely no banner ever" is selling something. What a privacy-first tool can honestly promise is that it gives you the shortest possible thing to disclose.

Identifiers: the part that actually matters

Analytics has to tell a returning user from a new one, and how it does that is the whole privacy story. There are only five approaches in common use, and they are not equally fine.

Identifier approaches compared
Approach	What it means	Verdict
IDFA	Apple's advertising identifier, shared across apps by design.	Tracking. ATT prompt required.
Fingerprinting	Working out a stable id from device signals: model, locale, screen, fonts.	Tracking, and against the rules even with a prompt.
Random install id	An id minted on first run, meaningless outside your app.	Fine. Not linked, no prompt.
Hashed user id	Your account id, scrambled on the device before it is sent.	Fine, and stronger, though you cannot reverse it either.
Email or account id	Sent as it is and stored against the install.	Legitimate, but it is personal data: linked label, disclosure, deletion.

One detail worth asking about: where the random id is stored. In the iOS Keychain it survives a delete-and-reinstall, so one person counts once. In plain storage, every reinstall looks like a brand new user and your numbers quietly inflate.

"Where are my users?" without location data

A country map is one of the most useful things analytics shows, and one of the easiest to get wrong. There are two ways to draw it. From the device's region setting, which is a preference the user picked next to their language and date format and is not location data. Or from a geo-IP lookup, which means processing an IP address, and in the EU an IP address is personal data. Same map on screen, different privacy label. The two paths drawn out side by side →

Ten questions to ask any analytics SDK

Send these to a vendor and see how fast the answers come back. A tool that answers all ten quickly and in writing is a privacy-first tool. One that answers with a marketing page is not.

1. Do you touch the IDFA or the AdSupport framework at all? Want to hear: no, there is no such code

2. What identifier represents a user, and where is it stored? Want to hear: a random id, in the Keychain

3. Do you do anything that could be called fingerprinting? Want to hear: no, with no hedging

4. Is country worked out from the locale or from the IP address? Want to hear: the locale

5. Are IP addresses ever written to the analytics database? Want to hear: never stored, never attached to events

6. Which country is the data stored in, and under whose jurisdiction? Want to hear: a specific country, named

7. Can I delete one user's data, all of it, on demand? Want to hear: yes, immediately, from the dashboard

8. Is the SDK source readable, with a privacy manifest and signature? Want to hear: yes, here is the repository

9. Is my data used for anything except showing it back to me? Want to hear: no model training, no benchmarks, no ads

10. What exactly do I tick on the App Store form, in your default setup? Want to hear: a specific, short list

Copy this into an email. The right-hand column is what a good answer sounds like, not what a vendor is obliged to say.

Privacy manifests and required-reason APIs

Since 2024 Apple requires a privacy manifest, a file called PrivacyInfo.xcprivacy, that declares the data types you collect and your reasons for calling certain APIs, UserDefaults and file timestamps among them. SDKs on Apple's commonly-used list have to ship both a manifest and a code signature. If your analytics SDK does not include one, you inherit the paperwork. If it does, you only declare your own app's use.

How AppGlance answers all of this

Identity: a random id in the Keychain, so reinstalls count once. No IDFA, no fingerprinting.
Country: the device region setting by default. Never GPS. Per app you can switch it to a geo-IP lookup at the edge, or off entirely.
IP addresses: our infrastructure sees them like every server does, and they are never written to the analytics database or attached to events.
Where it lives: Postgres in the EU (Ireland), made in Norway.
Deletion: delete an app and every event it recorded goes immediately. A per-user delete handles individual "forget me" requests.
Source: the SDKs are MIT-licensed and dependency-free on Apple platforms, and the Swift package ships its own privacy manifest.
Identity, if you want it: identify is opt-in and off by default, and the dashboard shows you exactly how your privacy label changes before you enable it.
Your questionnaire: generated, not guessed, for both the App Store and Google Play.

The full detail is in the privacy policy and the SDK documentation. Comparisons with the two tools people usually weigh this against: Firebase and TelemetryDeck.

Two lines of code, and a label that stays short

Free up to 100,000 events a month. No credit card, no consent banner, no ATT prompt.

Start free Open the demo