Play Integrity API: Mobile App Attestation
Mobile apps do not just check your IP. They ask the operating system to prove the device is genuine, the app binary is unmodified, and the install is legitimate. Here is how that attestation layer works on Android and iOS - and why it sits below anything a proxy can touch.
Quick Answer
Mobile app attestation is a device-layer check. Google's Play Integrity API and Apple's App Attest use hardware-backed signals to confirm an app is genuine and running on an untampered device. A mobile proxy changes your network identity, not the device, so it does not defeat attestation.
- →Attestation checks device integrity, app integrity, and account/licensing signals
- →Play Integrity replaced SafetyNet Attestation; Apple uses App Attest + DeviceCheck
- →A clean carrier IP still matters for network reputation and geo - a separate layer
This is a neutral, technical explainer, not a guide to defeating any platform's protections. Most proxy and fingerprinting content focuses on the browser and the network. Native mobile apps add a layer that web pages cannot: they can ask the operating system, and dedicated hardware inside the phone, to vouch for the device. If you have read how websites detect proxies or how DataDome works, this is the mobile-native counterpart - and it is worth understanding precisely where a mobile proxy helps and where it is simply irrelevant.
What app attestation actually checks
"Attestation" means the platform issues a signed statement about the state of the client. Instead of trusting a value the app reports about itself, the app's backend receives a token produced by Google or Apple that it can verify server-side. Broadly, attestation answers three questions at once:
Device integrity
Is this a genuine, certified device that is not rooted, jailbroken, or emulated?
App integrity
Is this the real, unmodified app binary distributed through the official store?
Account / licensing
Does this install correspond to a legitimate account entitlement?
A large part of device integrity is root and emulator detection. Unlocked bootloaders, custom ROMs such as LineageOS, rooting frameworks, and emulators change the trusted boot chain, and attestation is designed to notice. The signal that matters is not your IP address - it is the cryptographic state of the hardware and OS underneath the app.
Google Play Integrity API and its verdict tiers
The Play Integrity API is Google's successor to the older SafetyNet Attestation API. Google deprecated SafetyNet Attestation and directed developers to migrate, with the legacy service fully turned down in 2025. When an app calls Play Integrity, Google Play Services runs a set of checks and returns a signed token to the app's server. Two fields do most of the work.
The device integrity field can carry these labels, per Google's developer documentation:
MEETS_DEVICE_INTEGRITY
The default verdict: the app runs on a genuine, Play-certified Android device. On Android 13 and higher this carries hardware-backed proof that the bootloader is locked and the loaded OS is a certified manufacturer image.
MEETS_BASIC_INTEGRITY (opt-in)
The device passes basic checks but the bootloader may be unlocked and the device may not be certified - a looser bar.
MEETS_STRONG_INTEGRITY (opt-in)
The strongest tier: device integrity plus, on Android 13 and higher, evidence of a recent security update, backed by hardware-rooted boot integrity.
Empty / blank verdict
No label is returned when there are signs of attack, rooting, or an emulator that fails Google Play's integrity checks.
Alongside device integrity, an app integrity field reports whether the running binary matches what Google Play distributes (PLAY_RECOGNIZED vs. UNRECOGNIZED_VERSION), and an account-details field reports a licensing verdict (LICENSED vs. UNLICENSED). None of these read or depend on your exit IP.
Apple App Attest and DeviceCheck
Apple's equivalents live in the DeviceCheck framework. App Attest establishes that an app is a genuine, unmodified build running on a real Apple device. On first use, the app asks the system to generate a public/private key pair inside the Secure Enclave, the dedicated security coprocessor. The private key never leaves that hardware and cannot be extracted, even if the main application processor is compromised. Apple then returns an attestation, signed by Apple, certifying that the key pair originates from a genuine Apple device.
From then on, the app can sign requests ("assertions") with that key. The app's server validates the certificate chain against Apple's root and checks each assertion's signature and counter. Because the keys are unique per app installation and are not backed up or synced across devices, a valid attestation is strong evidence of a real, untampered install.
DeviceCheck is the lighter companion. It lets a server store a tiny amount of per-device state (two bits) on Apple's infrastructure and read back risk signals, so a backend can remember a device across reinstalls - useful for things like one-per-device promotions. Both are hardware-backed and device-scoped. Neither has anything to do with the network path the request travels.
Why a mobile IP does not defeat attestation
This is the crux for a mobile-first audience. Attestation operates at the device layer. Play Integrity is computed by Google Play Services on the phone and signed by Google; App Attest is rooted in a key inside Apple's Secure Enclave. The verdict is about the hardware, the boot state, and the app binary.
A proxy - mobile, residential, or datacenter - only changes the network layer: the route packets take and the public IP the server sees. It cannot forge a Secure Enclave key, relock a bootloader, or make a rooted phone report a clean boot chain. So swapping in a 4G/5G carrier IP does not change a device-integrity verdict. If the device fails attestation, a pristine IP will not rescue it; if it passes, the IP was never part of that decision.
Put plainly: proxies answer "where is this traffic coming from?" Attestation answers "what device and app is behind it?" They are different questions, checked by different systems.
Where a clean carrier IP still matters
Attestation is not the whole story. Most mobile backends layer several independent checks, and the network reputation of your IP feeds a different set of them. A clean, real carrier IP is relevant to:
- •Network reputation and fraud scoring - datacenter ranges and abused IP pools are weighted against you independently of any device verdict.
- •Geolocation and region gating - content, pricing, and availability that key off where the IP resolves.
- •Rate limiting - how aggressively a service throttles traffic from a given address or range.
Carrier IPs carry higher default trust here, in part because of how mobile networks are built. Most subscribers on a carrier share a pool of public addresses through carrier-grade NAT (CGNAT), so a single mobile IP represents many real users, which detection systems have to account for. We cover that dynamic in CGNAT and mobile-proxy fingerprinting.
The honest framing for a mobile audience is a division of labor. A mobile proxy is the right tool for the network-reputation and geo layers - for example when spreading account creation across clean, geographically appropriate IPs, as we discuss for Instagram account creation. It is simply out of scope for device attestation, which depends on the physical phone and its operating system. Treat the two as separate problems and choose tools accordingly.
Frequently asked questions
What is the difference between the Play Integrity API and SafetyNet Attestation?
The Play Integrity API is Google's successor to the SafetyNet Attestation API. Google deprecated SafetyNet Attestation and directed developers to migrate, completing the legacy turndown in 2025. Play Integrity returns richer verdicts covering device integrity, app integrity, and licensing, and can require hardware-backed signals on newer Android versions.
Can a mobile proxy bypass Play Integrity or Apple App Attest?
No. Attestation operates at the device layer. Play Integrity evaluates the device, the app binary, and the Play licensing state, while Apple App Attest relies on a key in the Secure Enclave. A proxy only changes the network path and exit IP, so it neither helps nor hurts a device-integrity verdict.
What do MEETS_DEVICE_INTEGRITY and MEETS_STRONG_INTEGRITY mean?
MEETS_DEVICE_INTEGRITY means the app is running on a genuine, certified Android device; on Android 13 and higher it carries hardware-backed proof that the bootloader is locked and the OS is a certified image. MEETS_STRONG_INTEGRITY adds a requirement for a recent security update. A blank verdict signals rooting, tampering, or an emulator.
What is Apple App Attest and how is it different from DeviceCheck?
App Attest proves an app is a genuine, unmodified build running on a real Apple device using a key pair generated in the Secure Enclave and certified by Apple. DeviceCheck is a lighter service that stores a small amount of per-device state and exposes risk data, letting a server remember a device across installs.
Do rooted phones or emulators pass app attestation?
Generally no. Rooted devices, unlocked bootloaders, custom ROMs, and emulators typically fail to earn a device-integrity verdict from Play Integrity, and they cannot produce a valid Secure Enclave attestation on iOS. This is by design, since attestation is meant to detect exactly those modified environments.
If a mobile proxy does not defeat attestation, when does it still matter?
A clean carrier IP still matters for the network-reputation and geolocation layers that sit alongside attestation, such as fraud scoring, rate limiting, and region gating. It is simply out of scope for the device-integrity check itself, which is why the two layers should be reasoned about separately.
Sources
Related Guides
Get the network layer right
Attestation is the device's job. For the layer a proxy does own - clean, geo-matched 4G/5G carrier IPs - test our network for $5.