App Attest and DeviceCheck App Review checklist
App Attest can protect server resources, but it can also lock out review devices if support checks, sandbox/prod separation, and fallback behavior are not designed.
Use App Attest to help your server verify legitimate app instances, but handle unsupported devices, key creation failure, environment mismatch, reinstall, and review accounts gracefully. Apple DeviceCheck documentation describes App Attest for asserting app validity to a server. AppReviewReady interpretation: build an attestation fallback contract before enforcing hard blocks.
Decide what App Attest protects
Name the server resources protected by attestation: account creation, purchase validation, high-risk API calls, fraud-sensitive actions, game economy, or private data access. Do not enforce App Attest everywhere before understanding unsupported states.
A review account should exercise the protected path without being blocked by a developer-only environment mismatch.
Handle unsupported and failure states
- Check support before attempting attestation.
- Separate sandbox and production environment behavior.
- Handle key generation failure, invalid key, server validation failure, reinstall, and device migration.
- Avoid revealing fraud-detection details in user-facing errors.
- Provide support recovery for legitimate users who are falsely blocked.
Keep server enforcement observable
The server should log attestation decisions in a way support and security can investigate without storing unnecessary device or user data. A generic 403 is difficult to debug during review and after launch.
AppReviewReady interpretation: distinguish risk scoring from user punishment. A failed attestation can require step-up checks or limited access before it becomes a hard account block.
Test integrity edge cases
- Run on supported device, unsupported device, simulator, TestFlight, and production build where appropriate.
- Delete and reinstall the app, then create a new key or recover according to policy.
- Force server validation failure and confirm the app shows a supportable error.
- Test protected purchase, login, sync, and content endpoints with and without attestation.
- Verify privacy labels and policy cover device integrity signals if collected.
Prepare App Attest review evidence
Review Notes do not need to expose security internals. They should ensure the reviewer can complete the app's core path without being mistaken for fraud.
After launch, monitor attestation failures by OS version, device class, app version, and build channel. A sudden spike can indicate a server rollout issue rather than real abuse.
If the app uses App Attest to protect paid content, support should have a recovery path that does not ask users to reveal device secrets or weaken account security.
Roll out enforcement gradually when possible, and keep a server-side kill switch for false-positive spikes during a new release.
For review builds, verify the same server policy applies to the submitted binary that will reach customers. A special reviewer bypass can hide production enforcement bugs that later block legitimate purchases or account creation.
App Attest review path: Protected actions: [list] Environment: [production/sandbox] Unsupported behavior: [fallback] Review account: [credentials] Failure message: [text] Server logging: [decision only] Support recovery: [route]
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Check app integrity readiness
Review App Attest enforcement, fallback, server validation, and reviewer access.
Open the tool