Device fingerprinting is the practice of identifying a device, and through it a user, by combining its characteristics rather than asking for a declared identifier, and both Apple and Google restrict it. The reason the required-reason APIs exist on iOS is precisely that signals like device settings and timing were being combined to fingerprint and track users who had not consented. For a mobile app, fingerprinting to identify or track users is a privacy and policy problem that can lead to rejection, even when an SDK does it on your behalf. Here is what fingerprinting is, why the platforms restrict it, and how to stay clear.
Short answer
Device fingerprinting identifies a device, and through it a user, by combining its characteristics, model, settings, identifiers, timing, sensor data, rather than using a declared identifier the user can control. Per Apple's guidance, using device signals to fingerprint or identify a user without consent is not allowed, which is why the required-reason APIs exist and why your privacy disclosures and App Tracking Transparency apply. Google Play similarly restricts using device data to build persistent identifiers or circumvent user privacy controls. So do not fingerprint users for tracking, declare the required-reason APIs you use, respect user consent, and remember an SDK that fingerprints on your behalf is still your responsibility.
What you should know
- Fingerprinting combines device traits: to identify a device without a declared ID.
- Platforms restrict it: identifying users this way without consent is not allowed.
- Required-reason APIs target it: those APIs were used for fingerprinting.
- SDKs may fingerprint for you: which is still your responsibility.
- Consent and declared IDs are the way: respect ATT and privacy controls.
What is device fingerprinting?
It is recognizing a device by its combination of characteristics rather than by an identifier it presents. Any single attribute, the model, OS version, language, screen, time zone, available storage, boot time, installed components, is not unique, but combined they can be distinctive enough to single out a device, and persistent enough to recognize it again later, which lets a party track a user across sessions or apps without an identifier the user can reset or refuse. That is the privacy problem: fingerprinting works around the user's control. It is sometimes used for legitimate fraud detection, but it is also a tracking technique that bypasses the identifiers and consent mechanisms platforms provide, which is why combining device signals to identify a user is treated as fingerprinting and restricted, regardless of the stated intent.
Why do the platforms restrict it?
Because it undermines the user's control over being tracked. The table shows the platform stance.
| Mechanism | Why it relates to fingerprinting |
|---|---|
| Required-reason APIs (iOS) | Cover APIs that were used to build device fingerprints |
| App Tracking Transparency | Requires consent to track users across apps |
| Privacy disclosures | Must reflect data used to identify users |
| Google Play data policies | Restrict persistent identifiers and circumventing controls |
Apple introduced the required-reason APIs precisely because signals like UserDefaults access, disk space, boot time, and file timestamps were being used to derive a stable device fingerprint, and it requires you to declare an approved reason for using them and prohibits using them to fingerprint users. App Tracking Transparency adds that tracking users across apps needs consent, and fingerprinting to identify a user is a form of the tracking that consent governs. Google Play likewise restricts using device data to build persistent identifiers or to get around user privacy controls. The common thread is that fingerprinting evades the user's choice, which is what the platforms protect.
How do you stay on the right side?
Use declared identifiers with consent, and do not combine signals to identify users. Identify users and devices through identifiers the platform provides and the user can control, with consent where required, rather than deriving a hidden fingerprint from device characteristics. If you use App Tracking Transparency, get the user's permission before tracking across apps, and keep your privacy disclosures accurate about what you collect and why. Declare the required-reason APIs you use with an approved reason, and make sure you are not using those APIs to build a fingerprint. Crucially, audit your SDKs, since an analytics, ads, or anti-fraud library may fingerprint on your behalf, which is still your responsibility and can violate the rules and your disclosures. Where you need fraud signals, use sanctioned mechanisms and consent rather than covert fingerprinting. The aim is identification the user can see and control, not a fingerprint that bypasses them.
What to watch out for
The first trap is combining device signals to track users without consent, which is the fingerprinting platforms prohibit, and which the required-reason APIs were created to curb. The second is an SDK that fingerprints on your behalf, which is still your responsibility and can break your privacy disclosures. The third is using required-reason APIs without declaring an approved reason, or using them to fingerprint. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled binary against OWASP MASVS and surfaces the SDKs and required-reason API usage in your build, which helps you spot a library that may be fingerprinting before it becomes a privacy or policy problem. The consent and identifier choices you make in the app.
What to take away
- Device fingerprinting identifies a device, and through it a user, by combining its characteristics, working around the identifiers and consent the user controls.
- Apple and Google restrict it: identifying users this way without consent is not allowed, and iOS required-reason APIs exist because those signals were used to fingerprint.
- Use declared identifiers with consent, respect App Tracking Transparency, declare required-reason APIs honestly, and do not use them to fingerprint.
- Audit your SDKs, since a library fingerprinting on your behalf is still your responsibility, and use a pre-submission scan such as PTKD.com to surface it.
