We are implementing a one-free-trial-per-device rule for an iOS app. Our server uses App Attest to validate the app instance and DeviceCheck’s per-device bits to record that the device has received its trial. We grant the trial only after the server can confirm that the DeviceCheck bit was successfully stored. The unresolved case is when our server sends an update request to Apple, but the connection times out or closes before receiving a response. Apple may have accepted the write even though our server does not know the outcome. What is Apple’s recommended recovery procedure for this situation? Specifically: After an uncertain update response, can the server query the device’s bits to authoritatively determine whether the update succeeded? Does DeviceCheck provide read-after-write consistency for this query? If the queried bit is still unset, is it safe and supported to retry the update using the same desired bit values? Are repeated updates that set the bits to their existing values idempotent? Which response, if any, should be treated as confirmation that the write is durable before granting the trial? Our current design fails closed: it does not grant the trial when the write outcome is uncertain. We want to avoid both granting multiple trials and permanently denying an eligible user because of a transient network failure.

I'm building an iOS app (bundle identifier ca.fanforge.pos, Team ID 856C6JT832) that uses a third-party payment SDK to connect to a physical Bluetooth card reader. The SDK requires my app to successfully complete Apple's App Attest process against the production environment before it will allow a real card reader to connect. I have set the entitlement com.apple.developer.devicecheck.appattest-environment to production in my app's entitlements, and I have enabled the App Attest capability on my App ID in the Apple Developer portal. I confirmed directly, by extracting the compiled app binary and running codesign -d --entitlements :- MyApp on it, that the entitlement is present with the value production in the actual signed binary, not just in my source configuration. When I distribute this exact build as an ad-hoc build (a registered test device added to my provisioning profile, not through TestFlight or the App Store), the card reader fails to connect with an error indicating it cannot establish a secure connection to the payment provider's servers. When I distribute the identical app (same version, same entitlements, same provisioning) through TestFlight instead, the card reader connects successfully and I am able to process a real payment. Steps I have already taken to rule out other causes: Verified the payment provider's account credentials are valid and correctly configured for production (confirmed via a direct API call returning a successful response) Verified the App Attest capability is enabled on my App ID in the Apple Developer portal Verified the entitlement value directly in the compiled binary's code signature (not just my source files) Registered the required application signature with the payment provider Fully removed and reinstalled the app between tests Confirmed the reader hardware itself works correctly (it connects successfully in the TestFlight-distributed build) My question: Does ad-hoc distribution have different behavior than documented for the com.apple.developer.devicecheck.appattest-environment entitlement? Apple's documentation states that after distribution through TestFlight, the App Store, or the Apple Developer Enterprise Program, an app automatically uses the production App Attest environment regardless of the entitlement value. It also states that for other distribution methods, the entitlement value itself should directly control which environment is used. My ad-hoc build has the entitlement explicitly set to production, yet its behavior matches what I would expect from the sandbox environment, not production. Expected outcome: I would like to understand whether ad-hoc distribution is expected to correctly honor an explicit production entitlement value for App Attest, or whether there is a known limitation or additional requirement for ad-hoc distribution specifically that isn't covered in the entitlement's documentation.

Hello, Since we enabled App Attest in our production app on Aug 13, 2026, a small subset of users consistently fails attestation with DCError.invalidKey. For multiple confirmed devices the failure appears to be permanent: attestKey rejects even newly generated keys, and reinstalling the app, rebooting the device, or updating the app does not help. Environment Production builds from the App Store, real devices only, production App Attest environment Attestation succeeds for the vast majority of users (about 70,000 keys registered so far) Primary case (user-reported, verified end to end): iPhone XS Max, iOS 17.6.1, region US. 34 invalidKey events since Aug 13; no attestation record on our server; reinstall and reboot did not help Other devices showing the same persistent pattern in our internal logs (each of these reported invalidKey exclusively): iPhone X, iOS 16.7.16: 69 events over 16 days iPhone X (a second device), iOS 16.7.16: 60 events over 17 days iPhone 8, iOS 16.7.16: 12 events over 7 days iPhone XR, iOS 18.7.9: 11 events over 7 days We also see a smaller number of devices failing persistently with unknownSystemFailure instead of invalidKey, for example an iPhone XR on iOS 18.6.2 with 39 events over 15 days In our internal logs, App Attest errors in general appear across a range of iOS versions and devices Implementation flow DCAppAttestService.shared.generateKey attestKey(_:clientDataHash:) with a SHA-256 hash of a server-issued nonce On failure we retry up to 3 times, with backoff intervals of 0.5, 1, and 2 seconds. For DCError.invalidKey, each retry discards the previous key and generates a brand-new key before calling attestKey again; for serverUnavailable we retry with the same key and clientDataHash, per the DCError header guidance Error characteristics For the affected device, all 3 attempts fail with DCError.invalidKey (com.apple.devicecheck.error code 3), even though every attempt uses a newly generated key ID The failure has persisted continuously since Aug 13, 2026 (19 days and ongoing at the time of writing) App reinstall and device reboot do not resolve it, and the failure has persisted across three consecutive app versions Our server has no attestation record for this user at all, so the key has never been successfully attested; this is not a case of a stale or previously attested key being reused The device supports App Attest. For some users of our sibling app in Japan the same error was transient: they hit invalidKey and then attested successfully later, so invalidKey is clearly transient in some cases but appears permanent in others Scale Our internal logs show 478 attestation-failure events from 61 users between Aug 13 and Sep 1, across all DCError codes Of those, at least 298 events from 30 users are invalidKey, roughly 0.01 percent of our active users (about 360,000) What we have ruled out Key reuse: every retry generates a fresh key clientDataHash handling: identical code succeeds for 99.99 percent of users Server-side verification: the failure happens client-side in attestKey, before our server is ever contacted Account state: the affected user is in good standing Questions Under what conditions can attestKey return invalidKey for a freshly generated key? The documentation describes invalidKey as an invalid key identifier, but here the key ID comes directly from a just-completed generateKey call. Is there any known device-side or Apple-server-side state that can cause a specific device to fail attestation persistently (for weeks, across reinstalls and reboots)? If so, is there anything the user or we can do to remediate it? Is there a recommended way to distinguish between a transient failure, a permanent device-level failure, and an Apple-side service issue, or to get more diagnostics for these failures in production? The NSError carries no information beyond the DCError code, which does not seem to differentiate these cases. Is the guidance from earlier threads (for example thread 812308) still current, that is: should we treat a device that persistently fails attestation as if App Attest were unsupported and fall back accordingly? We are hesitant because that fallback becomes an obvious bypass path for bad actors. Could this be related to throttling or rate limiting of attestKey? Our retries are capped at 3 attempts per verification flow, with 0.5 to 2 second backoff. Any insight would be greatly appreciated. Thank you.

I’m implementing server-side App Attest validation and trying to verify my implementation against Apple’s published Attestation Object Validation Guide sample. I have already filed Feedback Assistant report FB24281098. Using only the values published in Apple’s sample, I can reproduce four apparent inconsistencies: Nonce calculation The documented procedure says to compute: clientDataHash = SHA256(clientData) and then: nonce = SHA256(authenticatorData || clientDataHash) Using the published server challenge, this produces: 1d1ce78912897de88cfe9fce5521aab37abfb09dc544833ff115612552cf75f3 However, the nonce contained in the sample certificate / published expected nonce is: 87b7d06d93a4294e46f011e66b6cc400f0bab20729976c619580b42ae60bff6e That value is reproduced when the raw challenge is appended to authenticatorData instead of SHA256(challenge). The block labeled “Expected clientDataHash” also appears substantially longer than a 32-byte SHA-256 digest. Public-key hash / key ID SHA256 of the leaf certificate’s X9.62 uncompressed P-256 public key is: ce0498f58483fbb4da0d7b2c63a5a538f552d4adcb9a4fa916195c49613e655d This matches the decoded key ID / credential ID from the attestation object. However, the separately published expected public-key hash is: 8a71a32b625b68012102c6300a7b36cd3c990f3b09dce2b1dd0da79f193e9a46 which appears to be SHA256 of the key-ID bytes instead. Bundle version The sample certificate extension contains the value "1", while the guide prose describes "1.0". Validation category The sample extension contains four bytes 01 00 00 00, while the guide describes the value as UInt32 category 1. I’m looking for clarification on the authoritative wire representation / parsing rule. Could Apple please confirm the authoritative byte-level behavior for these four fields, particularly: whether the nonce must use SHA256(clientData) as documented; whether the key ID must equal SHA256 of the X9.62 uncompressed public key; the exact bundle-version comparison rule; and the canonical validation-category representation? I’m intentionally avoiding accepting multiple interpretations or adding fallback behavior in a security-sensitive server verifier, so clarification from Apple would be greatly appreciated.

Issue Summary We are seeing consistently high latency when calling DCAppAttestService.shared.attestKey(_:clientDataHash:). The call routinely takes 4–5 seconds in the development environment and 7–8 seconds in production. In contrast, other DeviceCheck operations execute very quickly on the same setup (e.g., DCDevice.generateToken takes ~100ms, and generateAssertion takes ~80ms). Environment Details Platform: iOS (reproduced on physical devices) Framework: DeviceCheck / App Attest Entitlements: com.apple.developer.devicecheck.appattest-environment set appropriately for each environment (development / production) Execution Flow: generateKey (or keychain lookup) $\rightarrow$ attestKey $\rightarrow$ generateAssertion Representative Timings (Development / Physical Device) ensureKey (keychain reuse): 5 ms generateDeviceToken: 91 ms attestKey (Apple API execution): 5,196 ms generateAssertion: 76 ms Total Wall Time: ~5,505 ms Steps to Reproduce On a physical iPhone, invoke DCAppAttestService.shared.generateKey() (or retrieve an existing keyId). Generate a client challenge hash (SHA256). Invoke attestKey(_:clientDataHash:completionHandler:) with the keyId and hash. Observe the multi-second delay before the completion handler returns the attestation statement. Questions & Guidance Requested Expected Baseline: Is 4–8 seconds for a successful attestKey call considered expected behavior for Apple’s attestation servers, or does this indicate an anomaly? Environment & Regional Latency: Are there known factors (e.g., server geographic routing, network handshakes, or environment differences) that cause attestKey to be noticeably slower in production compared to development? Mitigation / Best Practices: Since attestation is recommended once per key/device lifecycle upon key generation, are there specific architectural patterns Apple recommends to avoid blocking UI or onboarding flows during this high-latency step? Note: We can supply full sysdiagnose logs, device model/iOS version breakdowns, and code snippets if required.

Dear Apple Developer Support, We are currently encountering a recurring issue with the DeviceCheck API across multiple devices in our production environment. The following error is frequently returned: com.apple.devicecheck.error 0 We would like to ask the following: What are the possible underlying causes that could lead to this specific error code (0) in the DeviceCheck API? Is there any known behavior or condition where Wi-Fi network configurations (e.g., DNS filtering, proxy settings, captive portals) could result in this error? Are there known timeouts, connectivity expectations, or TLS-level requirements that the DeviceCheck API enforces which could fail silently under certain network conditions? Is this error ever triggered locally (e.g., client library-level issues) or is it always from a failed communication with Apple’s servers? Any technical clarification, documentation, or internal insight into this error code would be greatly appreciated. This would help us significantly narrow down root causes and better support our users

In the WWDC 2021 session Mitigate fraud with App Attest and DeviceCheck it is said that: App Attest is supported on devices that have a Secure Enclave, but there are cases, such as app extensions, where isSupported will still return false. The documentation shows that the following Macs have a Secure Enclave: MacBook Pro computers with Touch Bar (2016 and 2017) that contain the Apple T1 Chip Intel-based Mac computers that contain the Apple T2 Security Chip Mac computers with Apple silicon I'm using a 2018 15" MacBook Pro containing a T2 Security Chip for testing, however, DCAppAttestService.shared.isSupported always returns false in native macOS or Catalyst apps. DCDevice.current.isSupported also returns false. The documentation for DCAppAttestService shows availability on "macOS 11.0+" and "Mac Catalyst 14.0+". It appears to have been added in the macOS 11.3 SDK included in Xcode 12.5. DCDevice shows availability on "macOS 10.15+" and "Mac Catalyst 13.0+". Although both APIs are available on the listed OSes, I only ever see isSupported == false. Are App Attest or DeviceCheck functional on any Macs? If so: Are there more specific Macs that support the feature (e.g., Apple Silicon Macs only)? Are there any additional steps that need to be taken to use them (e.g., changes to entitlements, provisioning profiles or distribution through the Mac App Store)? In native macOS apps, it doesn't actually appear to be possible to add the App Attest capability in Xcode under "Signing & Capabilities". If not, I think it would be good to update the documentation with this limitation since I'd expect them to work based on the availability being "macOS 10.15+" or "macOS 11.0+" for DeviceCheck and App Attest, respectively. I imagine most others would make the same assumptions.

Im trying to Register free developer account but it’s asking for $99

Hello, I was planning to transfer an app to a different Apple Developer account and had a question regarding DeviceCheck behavior after the transfer. Currently, the app uses the DeviceCheck service with a DeviceCheck key associated with the transferring account. We are specifically interested in the period immediately after the app transfer, but before the app has been updated under the recipient account. Could you clarify the following: Will DeviceCheck validations continue to function after the app transfer using the existing DeviceCheck key and "iss" value associated with the transferor account? Or will DeviceCheck requests begin failing until a new DeviceCheck key is generated under the recipient account and our backend is updated to use the new "iss" value? Any guidance on the expected transition behavior would be greatly appreciated. Thank you.

Symptom Production iOS app (TestFlight) using App Attest. Devices generate assertions via DCAppAttestService (through Firebase App Check, which forwards to Apple's validation infrastructure). The fleet was attesting cleanly at ~100% verified for the first ~7 days post-first-install per device — then collapsed to ~0% verified once the initial token's natural TTL expired and devices were forced to re-attest. Has stayed at ~0% for 3+ days. Affects all 4 physical TestFlight devices; not reproducing on simulators (which is expected — App Attest unavailable there). The downstream validator's metric specifically categorizes these as "invalid" — meaning a token reached it and was rejected as cryptographically invalid — not as "no token sent" / "unrecognized origin" / "outdated SDK." Environment iOS 26.x (26.3.1 confirmed on multiple devices). Team ID T68SS8UY5J, bundle com.calimento.app, App ID has App Attest capability checked. Entitlements signed into binary: com.apple.developer.devicecheck.appattest-environment = production. Xcode would refuse this embed if the App ID lost the capability — so capability state is verifiably intact. Provisioning profile UUID byte-identical between the last verified-traffic build and the first invalid-traffic build (confirmed via Xcode build logs). Same code-signing identity hash across both builds. TestFlight builds approved by Apple Beta Review. What's been ruled out Provisioning / signing / certificate drift (UUID and cert hash unchanged across builds). App ID capability revocation (entitlement embed succeeded). Firebase iOS app config drift (GoogleService-Info.plist byte-identical across vault, local working tree, and Firebase Console download). Token attachment / SDK init race (0% of requests in the "no token" or "outdated client" buckets). Pod / dependency drift (package-lock byte-identical between verified and failing builds). The integration was producing valid assertions for ~7 days post-install per device — code-side bugs would have manifested from day one, not synchronized to the TTL boundary. Questions Are there known iOS 26.x server-side issues with App Attest assertion validation that would cause hardware-generated assertions to be rejected as cryptographically invalid? Is there a documented or undocumented abuse-mitigation behavior that downgrades or invalidates assertions for an App ID under specific conditions — e.g., after a volume threshold within a window, or after a fingerprint anomaly? Looking specifically at whether high attestation churn during development can leave an App ID's attestation state in a degraded mode. Is there any way to inspect Apple's reason for rejecting a specific assertion — through a developer tool, console log, or feedback channel? The downstream validator only surfaces"invalid"; it doesn't report Apple's underlying rejection reason. Recovery semantics: if a device's keyId ends up internally blocklisted, does it age out, or is the device permanently unable to produce valid assertions for that App ID? appattest-environment = production validation flow: any way the production environment validator could differ from development in a way that produces this signature? Why I'm filing here rather than only with the SDK maintainer: The SDK is reliably attaching tokens (0% in the "no token" bucket). Origin is being recognized (0% in the "unknown origin" bucket). The rejection is happening at signature validation — which is downstream of any client-SDK behavior. Cross-filed with the React Native Firebase maintainers at [https://github.com/invertase/react-native-firebase/issues/9008]; if the root cause turns out to be on the wrapper's side, that thread will be closed. Happy to provide raw build logs, validator metric exports, or a build for a test device on Apple's side privately.

Hi folks, in my application I write some logs over debugPrint or directly over print. The application is already distributed and some part of functionality failed with application traceback. I would like to ask user for providing logs from the App. Is it possible to get those logs? Thanks Petr

We are currently experiencing an unexpected issue with the DeviceCheck query_two_bits endpoint. According to the official documentation (Accessing and Modifying Per-Device Data), the last_update_time field should represent the month and year when the bits were last modified. The Issue: For several specific device tokens, our server is receiving a last_update_time value that is set in the future. Current Date: April 2026 Returned last_update_time: 2026-12 (December 2026) Here is a response: { "body": "{\"bit0\":false,\"bit1\":true,\"last_update_time\":\"2026-12\"}", "headers": { "Server": ["Apple"], "Date": ["Thu, 02 Apr 2026 06:05:23 GMT"], "Content-Type": ["application/json; charset=UTF-8"], "Transfer-Encoding": ["chunked"], "Connection": ["keep-alive"], "X-Apple-Request-UUID": ["53e16c38-d9f7-4d58-a354-ce07a4eaa35b"], "X-Responding-Instance": ["af-bit-store-56b5b6b478-k8hnh"], "Strict-Transport-Security": ["max-age=31536000; includeSubdomains"], "X-Frame-Options": ["SAMEORIGIN"], "X-Content-Type-Options": ["nosniff"], "X-XSS-Protection": ["1; mode=block"] }, "statusCode": "OK", "statusCodeValue": 200 } Technical Details: Endpoint: https://api.development.devicecheck.apple.com/v1/query_two_bits (also occurring in Production) Response Body Example: JSON { "bit0": true, "bit1": false, "last_update_time": "2026-12" } Observations: This occurs even when our server has not sent an update_two_bits request for that specific device in the current month. Questions: Is there a known issue with the timestamp synchronization or regional database propagation for DeviceCheck? Does the last_update_time field ever represent an expiration date or any value other than the "last modified" month? Best regards,

Hi everyone, I'm integrating Apple's DeviceCheck API into my app and have run into a strange issue that I can't find documented anywhere. The Problem When I call Apple's DeviceCheck query endpoint (POST https://api.devicecheck.apple.com/v1/query_two_bits), the response occasionally returns a last_update_time value that is in the future — ahead of the current server time. Example response: { "bit0": true, "bit1": false, "last_update_time": "2026-05" // future month, not yet reached } What I've Checked My server's system clock is correctly synced via NTP The JWT token I generate uses the current timestamp for the iat field This doesn't happen on every device — only on some specific devices The issue is reproducible on the same device across multiple calls Questions Is last_update_time sourced from the device's local clock at the time update_two_bits was called? Or is it stamped server-side by Apple? Could a device with an incorrectly set system clock (set to the future) cause Apple's servers to record a future last_update_time? Is there a recommended way to validate or sanitize last_update_time on the server side to handle this edge case? Has anyone else encountered this behavior? Any known workarounds? Any insight would be greatly appreciated. Thanks!

Hi, We are implementing Platform SSO and using attestKey during registration via ASAuthorizationProviderExtensionLoginManager. Could you clarify whether the attestKey flow involves sending attestation data to an Apple server for verification (similar to App Attest in the DeviceCheck framework), or if the attestation certificate chain is generated and signed entirely on-device without any Apple server interaction? The App Attest flow is clearly documented as using Apple’s attestation service, but the Platform SSO process is less clearly described. Thank you.

We are moving to Apple Business Store for our b2b customers. On the "residential" apple store side there is testflight. What process would one test an app we provide to a b2b customer when using apple business store publishing? (I don't see any sort of test flight for apple business)

Hello, we are using DeviceCheck – App Attest in a production iOS app. The integration has been live for some time and works correctly for most users, but a small subset of users encounter non-deterministic failures that we are unable to reproduce internally. Environment iOS 14+ Real devices only (no simulator) App Attest capability enabled Correct App ID, Team ID and App Attest entitlement Production environment Relevant code let service = DCAppAttestService.shared service.generateKey { keyId, error in // key generation } service.attestKey(keyId, clientDataHash: hash) { attestation, error in // ERROR: com.apple.devicecheck.error 3 / 4 } service.generateAssertion(keyId, clientDataHash: clientDataHash) { assertion, error in // ERROR: com.apple.devicecheck.error 3 / 4 } For some users we intermittently receive: com.apple.devicecheck.error error 3 com.apple.devicecheck.error error 4 Characteristics: appears random affects only some users/devices sometimes resolves after time or reinstall not reproducible on our test devices NSError contains no additional diagnostic info Some questions: What is the official meaning of App Attest errors 3 and 4? Are these errors related to key state, device conditions, throttling, or transient App Attest service issues? Is there any recommended way to debug or gain more insight when this happens in production? Any guidance would be greatly appreciated, as this impacts real users and is difficult to diagnose. Thank you.

Hi, In our app we are using DeviceCheck (App Attest) in a production environment iOS. The service works correctly for most users, but a user reported failure in a flow that use device check service. This failure is not intermittently, it is constant. We are unable to reproduce this failure and we are believing that this failure occurred by new version ios 26.3 because for others users using early versions the service is normally. Environment iOS 26.3 Real device App Attest capability enabled Correct App ID, Team ID and App Attest entitlement Production environment Characteristics: appears constantly affects only unique user -Don't resolves after time or reinstall not reproducible on our test devices NSError contains no additional diagnostic info (Error Domain=com.apple.devicecheck.error Code=3 "(null)") We saw about this error code 3 in this post 812308, but it's not our case because the ios version in this case is not iOS 17.0 or earlier. Please, help us any guidance for solution. Thank you

We integrated DeviceCheck framework into our app to prevent fraudulent call to our app service around one year ago. Recently, we received a few cases related to this function over Christmas Eve period. Based on the logs we have, it indicated both the following two functions returned errors. But we don't have the exactly errors logged and now we cannot replicate. DCAppAttestService.shared.attestKey() DCAppAttestService.shared.generateAssertion() The other finding we have is some users reporting this issue recently upgraded their devices from iOS 18 to iOS 26. So we are suspecting it's due to either the OS upgrading, or Apple's app attest service degrading. Anyone encountered the similar issues before, or have any idea regarding the root cause? Thanks!

We're experiencing crashes in our production iOS app related to Apple's DeviceCheck framework. The crash occurs in DCAnalytics internal performance tracking, affecting some specific versions of iOS 18 (18.4.1, 18.5.0). Crash Signature CoreFoundation: -[__NSDictionaryM setObject:forKeyedSubscript:] + 460 DeviceCheck: -[DCAnalytics sendPerformanceForCategory:eventType:] + 236 Observed Patterns Scenario 1 - Token Generation: Crashed: com.appQueue EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000010 DeviceCheck: -[DCDevice generateTokenWithCompletionHandler:] Thread: Background dispatch queue Scenario 2 - Support Check: Crashed: com.apple.main-thread EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000008 DeviceCheck: -[DCDevice _isSupportedReturningError:] DeviceCheck: -[DCDevice isSupported] Thread: Main thread Root Cause Analysis The DCAnalytics component within DeviceCheck attempts to insert a nil value into an NSMutableDictionary when recording performance metrics, indicating missing nil validation before dictionary operations. Reproduction Context Crashes occur during standard DeviceCheck API usage: Calling DCDevice.isSupported property Calling DCDevice.generateToken(completionHandler:) (triggered by Firebase App Check SDK) Both operations invoke internal analytics that fail with nil insertion attempts. Concurrency Considerations We've implemented sequential access guards around DeviceCheck token generation to prevent race conditions, yet crashes persist. This suggests the issue likely originates within the DeviceCheck framework's internal implementation rather than concurrent access from our application code. Note: Scenario 2 occurs through Firebase SDK's App Check integration, which internally uses DeviceCheck for attestation. Request Can Apple engineering confirm if this is a known issue with DeviceCheck's analytics subsystem? Is there a recommended workaround to disable DCAnalytics or ensure thread-safe DeviceCheck API usage? Any guidance on preventing these crashes would be appreciated.

Help get access please