If your iOS backend needs to know that a request really came from your genuine app, and not a script, a tampered build, or a tool replaying your API, App Attest is Apple's answer. It uses a hardware-backed key in the Secure Enclave to let your server verify that a request originates from a legitimate, unmodified instance of your app on a real Apple device. Its companion, DeviceCheck, persists a small amount of per-device state for fraud and abuse use cases. Together they are the iOS counterpart to Android's Play Integrity. Here is what each does and how to use them well.
Short answer
App Attest lets your server verify that requests come from a genuine, unmodified instance of your app on a legitimate Apple device, using a hardware-backed key generated in the Secure Enclave that your backend validates with Apple. Per Apple's DeviceCheck documentation, its companion DeviceCheck lets you store and read a small amount of per-device data, useful for fraud and abuse cases like limiting a one-time offer per device. Both are anti-abuse and integrity tools, not absolute guarantees, so your backend verifies the attestation server-side and uses it to decide how much to trust a request. They are the iOS counterpart to Android's Play Integrity API.
What you should know
- App Attest verifies app integrity: requests come from your genuine, unmodified app.
- It is hardware-backed: the key lives in the Secure Enclave.
- DeviceCheck stores per-device bits: small state for fraud and abuse use.
- Verify server-side: your backend validates the attestation with Apple.
- It is anti-abuse, not absolute: a strong signal, not an unbreakable barrier.
What is App Attest, and what is DeviceCheck?
They are Apple's framework for app integrity and per-device state. App Attest has your app generate a key in the Secure Enclave and produce a cryptographic attestation that your backend, with Apple's help, verifies to confirm the request comes from a legitimate, unmodified instance of your app on a genuine Apple device. After the initial attestation, the app produces assertions for subsequent requests so your server can keep trusting them. DeviceCheck, the broader framework App Attest is part of, lets you set and read two bits of data and a timestamp that Apple persists per device even across reinstalls, which is handy for things like ensuring a free trial or promotional offer is used once per device. So App Attest answers "is this really my app on a real device," and DeviceCheck answers "have I seen this device before for this purpose," both backed by Apple rather than by data your app stores locally.
What does each provide?
Different anti-abuse capabilities. The table summarizes them.
| Capability | What it gives you |
|---|---|
| App Attest attestation | Proof a request comes from your genuine, unmodified app instance |
| App Attest assertion | Ongoing proof for subsequent requests after attestation |
| DeviceCheck bits | Two bits of per-device state persisted by Apple |
| Hardware backing | Keys generated and held in the Secure Enclave |
App Attest is the integrity piece: it lets your server distinguish requests from your real app from those by a script, an emulator, or a tampered build, which is valuable for protecting an API from abuse. DeviceCheck is the persistence piece: the per-device bits survive reinstalls, so you can track a device-level state like whether it has already claimed a one-time benefit, without storing personal data. Both rely on Apple as the verifier.
How do you use it well?
Verify server-side, and use it as one layer. The point of App Attest is that your backend verifies the attestation and assertions, so do that verification on the server, not the client, since a tampered client could otherwise lie about its own state. Use the result to decide how much to trust a request, adding friction or refusing a sensitive operation when integrity is in doubt, rather than treating it as a single pass or fail that hard-blocks legitimate users. Keep it as part of a layered defense: App Attest raises the cost of abusing your API, but you still enforce authorization server-side, keep secrets off the device, and protect data, because attestation confirms the app is genuine, not that every request is authorized. For DeviceCheck, treat the per-device bits as anti-abuse signals, not as identifiers for tracking. As with any attestation, it is a strong signal that can still be circumvented on a fully compromised device, so it deters rather than guarantees.
What to watch out for
The first trap is verifying the attestation on the client, which a tampered app can forge; verification belongs on your server. The second is treating App Attest as absolute and hard-blocking, when it is a probabilistic anti-abuse signal; use it to add friction. The third is leaning on it instead of real authorization, when it confirms the app is genuine, not that the request is allowed. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS and checks the static security of your build, storage, secrets, and network, which complements the runtime integrity App Attest provides, the same way a scan complements Android's Play Integrity. The two cover different layers.
What to take away
- App Attest lets your server verify that requests come from your genuine, unmodified app on a real Apple device, using a hardware-backed key in the Secure Enclave.
- DeviceCheck persists a small amount of per-device state for fraud and abuse cases, surviving reinstalls.
- Verify attestations and assertions server-side, use them to gate sensitive actions rather than hard-block, and treat them as one anti-abuse layer.
- App Attest is the iOS counterpart to Play Integrity; pair runtime attestation with a pre-submission scan such as PTKD.com that checks your build's static security.
