npx skills add ...
npx skills add dpearson2699/swift-ios-skills --skill device-integrity
Verify device legitimacy and app integrity using DeviceCheck (DCDevice per-device bits) and App Attest (DCAppAttestService key generation, attestation, and assertion flows). Use when implementing fraud prevention, detecting compromised devices, validating app authenticity with Apple's servers, protecting sensitive API endpoints with attested requests, or adding device verification to a backend architecture.
npx skills add dpearson2699/swift-ios-skills --skill device-integrity
Verify that requests to your server come from a genuine Apple device running a legitimate instance of your app. DeviceCheck provides per-device bits for simple flags (e.g., "claimed promo offer"). App Attest uses Secure Enclave keys and Apple attestation to cryptographically prove app legitimacy on sensitive requests.
DCDevice generates a
unique, ephemeral token that identifies a device. Treat each token as
single-use: generate a new token for each server operation instead of caching or
reusing one. The token is sent to your server, which then communicates with
Apple's servers to read or set two per-device bits. Available on iOS 11+.
The server exchanges each fresh token with Apple's authenticated DeviceCheck API. Load DeviceCheck Server Endpoints for endpoint and environment details.
Apple stores two Boolean values per device per developer team. You decide what they mean. Common uses:
Bits persist across app reinstall. You control when to reset them via the server API.
DCAppAttestService
validates that a specific instance of your app on a specific device is
legitimate. It uses a hardware-backed key in the Secure Enclave to create
cryptographic attestations and assertions. Available on iOS 14+.
The flow has three phases:
For app extensions, App Attest is supported only in Action, extensible SSO, and
watchOS extensions. Treat other extension types as unsupported even if
isSupported returns true.
Generate one cryptographic key pair per user account on each device. The
private key stays in the Secure Enclave. The returned keyId is the only
identifier your app can later use to access the key, so record and reuse the
account/device-scoped keyId; do not share one key across users. Avoid
unnecessary regeneration because each new key affects App Attest key-count risk
metrics. Only treat the keyId as usable after your server verifies
attestation. If server verification fails, discard the keyId and generate a
new key before retrying.
Attestation proves that the key was generated on a genuine Apple device running
a legitimate instance of your app. You perform attestation once per key, then
store the verified public key and receipt on your server. The app stores the
keyId for future assertions after the server accepts the attestation.
The server must verify the attestation before the client treats keyId as usable,
then store the verified public key and receipt. Load
Server-Side Attestation Verification
for the certificate, App ID, environment, counter, credential, and nonce checks.
After attestation, use assertions to sign sensitive requests. Each assertion proves the request came from the attested app instance and includes a server-issued, one-time challenge to prevent replay.
The server must verify each assertion's signature, RP ID, counter, one-time challenge, and request binding before authorizing the request. Load Server-Side Assertion Verification for the complete algorithm.
See references/device-integrity-patterns.md for full server architecture guidance including attestation vs. assertion comparison, recommended endpoint design, and risk assessment.
App Attest proves app-instance integrity for selected requests. It does not replace user authentication, OAuth/JWT/session handling, API token design, entitlement or subscription authorization, TLS, certificate pinning, or general networking security. Treat those as handoffs to authentication, networking, or broader security guidance, and still enforce normal authentication and authorization after App Attest passes.
Handle DCError codes from DeviceCheck operations. Key cases:
.serverUnavailable — retry with exponential backoff.invalidKey — the key was already attested, assertion used an unattested key, or the service rejected the key.featureUnsupported — fall back to DCDevice tokens.invalidInput — malformed clientDataHash or keyIdFor attestKey, retry .serverUnavailable later with the same keyId and the
same clientDataHash. For other attestation errors, discard the key identifier
and create a new key before retrying. See
references/device-integrity-patterns.md
for full error handling code, retry strategy, and rejected-key recovery.
Set the App Attest environment in your entitlements file. Use development
during testing and production for App Store builds. Load
Environment Entitlement
for the XML, default sandbox behavior, distribution behavior, and extension limits.
See references/device-integrity-patterns.md for the full integration manager pattern, gradual rollout guidance, and error type definition.
keyId, and keep key counts low.DCDevice tokens. Treat generated tokens as single-use. Generate a new token for each server operation.DCDevice tokens or other risk assessment as fallback.SHA256(authData || SHA256(challenge)), not SHA256(challenge) alone.DCError.invalidKey. Check for repeated attestation, unattested assertion keys, or service rejection; regenerate only after the state is known bad.DCDevice tokens generated per server operation and never cached for reuseDCAppAttestService.isSupported checked before use; unsupported devices and extension types have a fallbackkeyId persisted only for that app account/deviceaaguid, credential ID, and nonce SHA256(authData || SHA256(challenge))DCError cases handled: .serverUnavailable retries attestation with the same key/hash; bad keys are discarded and regenerated