Mobile device fingerprinting on iOS and Android.

Mobile device fingerprinting means recognising a returning iPhone, iPad or Android device for fraud prevention, and in apps it works differently from the browser. The platforms restrict what an app may read about a device, so the dependable approach is a random install identifier kept on the device, backed by integrity checks. Fingerly’s native iOS and Android SDKs work this way.

#How is mobile fingerprinting different from browser fingerprinting?

A website can learn a lot about a browser from ordinary characteristics. A native app lives under tighter platform rules: the system deliberately hides stable hardware identifiers, and the iOS platform rules restrict apps from deriving data from a device to identify it uniquely. An approach that is routine on the web can be rejected in an app.

That is why a browser SDK must never run inside an app’s web view, and why Fingerly ships separate native SDKs. In an app, a page is your app reading the device, and the native SDK is the tool built for that job.

#How does a mobile SDK recognise a returning device?

Fingerly’s iOS and Android SDKs create a random install ID, keep it in the app’s own storage on the device, and the server recognises the device by it. It never uses the advertising identifier or an operating system device identifier, and it is never shared with other apps. Device characteristics are used for integrity checks and the score, not to identify the device or the user.

Because recognition rests on the install ID, confidence in apps is simple: 100 for an install seen before and 0 for a new one, with no partial match. How a reinstall behaves differs by platform:

• On iOS, the install ID survives the app being deleted, so a reinstall on the same device keeps its visitor ID.
• On Android, the install ID is removed with the app and is never restored from a backup, so a reinstall gets a new visitor ID.
• Your app can call deleteStoredIdentity() to remove the install record for an erasure request or account deletion, after which the next identification starts a new ID.

#What do the iOS and Android SDKs report?

Each identification returns a request ID, the visitor ID, whether the visitor is new, a confidence value, and a suspect score and level. The score is computed on the server from raw input, so the SDK holds no weights or thresholds, and rules can change without an app update. Your backend can also see the signals behind it, such as a jailbroken or rooted device, an emulator or simulator, a cloned app, an instrumentation toolkit attached to the app, intercepted traffic, and VPN, proxy or Tor use.

Where the platform supports it, the SDK also supplies hardware-backed attestation, which lets the system vouch that a report comes from your genuine app. A modified app can forge everything else in a report, so attestation is the evidence that resists tampering. On Android 7.0 and newer it works without configuration. On iOS it is optional and needs the capability and your app identifier set up.

#How do you add device identification to an iOS or Android app?

Install the SDK, load it once with your public key, and call identify at the action you want to protect. The iOS SDK is written in Swift with no third-party dependencies, installs through Swift Package Manager, and needs iOS 13 or newer. The Android SDK is written in Kotlin, installs from Fingerly’s Maven repository, needs Android 5.0 (API 21) or newer, and has a callback wrapper for Java.

Cross-platform apps are covered by React Native, Flutter and Lynx packages that bridge to the same native SDKs. In every case the flow is the same: identify in the app, send the request ID to your backend with the action, and let the backend decide.

#Do the mobile SDKs need permissions or consent?

They never show a permission prompt. On Android the SDK declares two permissions, internet access and network state, which are granted at install time. The iOS SDK includes a privacy manifest inside the framework, so your app’s privacy report reflects it.

Consent defaults to pending, which collects nothing. Load the SDK as pending and pass your consent tool’s answer with setConsent, or load as granted where you already have consent or another lawful basis. Whether fraud prevention needs consent in your case is a question for your own legal advice.

Collection runs on a time budget, 1,200 milliseconds by default, and every source is isolated, so a slow or blocked one never holds up the answer. A screen that cannot wait can run only the fast tier of collection. Development and staging keys run the same detection as production and cost nothing, so you can test the flow on real devices, and on emulators and simulators, before you ship it.

#What should your backend do with the result?

Read the stored event with a secret key, using the request ID the app sent, and check it belongs to this action and is recent. The score that reaches the app is a convenience for trying the product and should not make security decisions, because the app runs on a device you do not control. Fingerly’s server SDKs, webhooks and HTTP API all read the same event.

Mobile behaviour described as the native SDKs ship today. See the SDK documentation for the full reference.