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 just says so.

What Apple means by "tracking" (it's narrower than you think)

Most of the confusion in this area comes from one word. In Apple's vocabulary, tracking is not "collecting data about users". It is specifically:

• linking data from your app with data collected by other companies' apps, websites or offline properties, for targeted advertising or advertising measurement; or
• sharing user or device data with a data broker.

Counting how many people opened your own app, keeping it to yourself, and never joining it to anyone else's data is 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 ATT prompt: when you genuinely need it

You need to call ATTrackingManager.requestTrackingAuthorization before accessing the IDFA or otherwise tracking, which in practice means: you run ads with attribution, you use an ad network's SDK, you share data for audience building, or you fingerprint devices. Note that Apple treats fingerprinting — deriving a stable identity from device signals, however cleverly — as tracking too, and it is not cured by asking permission; it's simply not allowed as a substitute for the IDFA.

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

App Privacy labels: three buckets, one honest answer

Every app answers the App Privacy questionnaire in App Store Connect, and the result appears on your store page in three buckets: 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:

• Identifiers → User ID — a random per-install id, not the IDFA.
• Usage Data → Product Interaction — sessions, screens, the events you track.

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

Consent banners: what GDPR actually asks

The cookie banners you see on the web come from the ePrivacy Directive's rule about storing or accessing information on a user'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 — no name, email, account id, ad identifier, IP-derived location, or cross-service identity — 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 (an email, your account id), you are processing personal data and you need a lawful basis, a privacy-policy disclosure, and a way to honour deletion requests.

Identifiers: the part that actually matters

Analytics has to tell one returning user from a new one, and how it does that is the whole privacy story:

A 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 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 — a locale the user chose, which is not Location data — or from a geo-IP lookup, which means processing an IP address, and an IP address is personal data in the EU. Same map, different privacy label. Ask which one your tool does.

Ten questions to ask any analytics SDK

1. Do you touch the IDFA or the AdSupport framework at all? (Should be: no.)
2. What identifier represents a user, and where is it stored?
3. Do you do anything that could be called fingerprinting?
4. Is country derived from the locale or from the IP address?
5. Are IP addresses written to the analytics database, ever?
6. Which country is the data stored in, and under whose jurisdiction?
7. Can I delete one user's data — and all of it — on demand, immediately?
8. Is the SDK source readable, and does it ship a privacy manifest and a signature?
9. Is my data ever used for anything other than showing it back to me? (Model training, benchmarks, ads.)
10. What exactly do I tick on the App Store questionnaire, in your default configuration?

A tool that answers all ten quickly and in writing is a privacy-first tool. One that answers with a marketing page is not.

Privacy manifests and required-reason APIs

Since 2024 Apple requires a privacy manifest (PrivacyInfo.xcprivacy) declaring collected data types and your reasons for calling certain APIs — UserDefaults and file timestamps among them — and SDKs on Apple's commonly-used list must ship both a manifest and a code signature. If your analytics SDK doesn't 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 UUID in the Keychain, so reinstalls count once. No IDFA, no fingerprinting.
• Country: the device region setting only. Never GPS, never geo-IP. Switchable off.
• IP addresses: our infrastructure sees them like every server does; they are never written to the analytics database or attached to events.
• Residency: Postgres in the EU (Ireland); made in Norway.
• Deletion: delete an app and every event it recorded is gone immediately; a per-user delete handles individual "forget me" requests.
• Source: the SDK is MIT-licensed, dependency-free, and ships its own privacy manifest.
• Identity, if you want it: identify is opt-in, off by default, and the dashboard shows you exactly how your privacy label changes before you enable it.
• Your questionnaire: generated, not guessed.

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.