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

How can I find out if my device is connected to another device and if their is an administrator that is controlling some of my actions and being able to see me and everything I do on my phone.

I am seeing recurring DCError.invalidKey in my iOS app using App Attest, and I'am trying to determine whether throttling or a quota can be a contributing factor before we look further. Questions Are there rate limits or quotas on generateKey, attestKey, or generateAssertion — scoped per device, per key, or per app? I understand exact thresholds may not be published; what I'd mainly like to know is whether such limits exist and roughly what timing window they apply over. If a limit is hit, which error surfaces? Specifically, can throttling ever present as DCError.invalidKey, or would it always be serverUnavailable (or another distinct code)? Does calling the attestation flow repeatedly in a short window (e.g. several times within a few minutes from an onboarding sequence) risk triggering throttling or anti-abuse rejection? Am I right that generateAssertion is entirely on-device and therefore not subject to any server-side limit — i.e. only attestKey contacts Apple's servers? Is throttling one of the documented causes of invalidKey, or is invalidKey strictly a key-state error (key absent from the Secure Enclave, already attested, from a prior install, etc.)? Being able to rule throttling in or out would help us narrow the investigation considerably. Thanks.

Hi Everyone I’m using an iPhone running the latest version of iOS with a physical team after enabling lockdown mode. I have noticed what appears to be unusual issued. 1: wi-Fi works normally. 2: outgoing cellular calls fail wit “call failed.” 3: shortly after the status bar changes to “no service.” 4: I still receive SMS notifications from my courier informing me of missed calls. I’ve already: . Nothing nice. updated to the latest iOS. . Restarted the iPhone. . Confirm that Wi-Fi is functioning normally. From Apple‘s documentation, I understand that lockdown mode is intended to harden the device against sophisticated cyber rates. I should not normally disable voice call service as everyone else experience this after enabling lockdown mode? If so: Which iPhone model are you using? Which iOS version? Which carrie? Did you find a solution? I’m also interested in knowing whether Apple is aware of this as a potential software bug or whether it could be related to a carrier compatibility issue. Thank you

Hey guys, I am having issue, unable to verify the app. An internet connection is required to verify trust of the developer .... I am connected to the internet, date and time is correct. I did some google, some one reported this link: https://ppq-ext.v.aaplimg.com/ ssl expired, which is causing this issue. Can anyone help? I am testing to test my app on Iphone 15 pro max.

I've been implementing App Attest on macOS 27 following the WWDC 2026 Session 201 announcement. DCAppAttestService.shared.isSupported always returns false on my M4 Mac running macOS 27.0 (26A5368g), even with the correct entitlement and a valid provisioning profile. What I have set up (correctly, as far as I can tell) com.apple.developer.devicecheck.app-attest-opt-in capability enabled in the Developer Portal (value CDhash) Entitlement present in both the binary and the embedded provisioning profile Developer ID signed, ProvisionsAllDevices: true The problem DCAppAttestService.shared.isSupported returns false from every process type I tested: An EndpointSecurity system extension A launchd daemon A sandboxed app running in user session generateKey() fails with com.apple.devicecheck.error code 1 (featureUnsupported). Root cause? (from devicecheckd logs) I see these logs devicecheckd: [com.apple.devicecheck:aai] FeatureFlagsManager.m:35 Mac feature flag enabled { enabled=1 }. devicecheckd: (AppAttestInternal) [com.apple.appattest:secl] SecurityController.swift:44 Failed to fetch value for entitlement. { entitlement=com.apple.devicecheck.daemon-client } devicecheckd: (AppAttestInternal) [com.apple.appattest:aahl] AppAttestHandler.swift:48 Client connection is ineligible. { clientUUID=nil } So the feature IS active in macOS 27 (Mac feature flag enabled=1), but devicecheckd immediately rejects any connecting process that doesn't hold the private entitlement com.apple.devicecheck.daemon-client. What is com.apple.devicecheck.daemon-client? Searching public entitlement databases shows this entitlement exists on iOSbut no macOS binary appears to hold it in any public database. It's not available to third-party developers via the Developer Portal. This check in SecurityController.swift:44 appears to be new in this beta. Questions Is com.apple.devicecheck.daemon-client the correct mechanism for third-party developers to use App Attest on macOS 27, or is this an internal gating mechanism that will be replaced/removed before GM? Is App Attest on macOS 27 fully available to third-party developers in this seed, or is it still restricted to Apple-internal testing? Is there a different entitlement or provisioning capability that third-party developers should request to allow DCAppAttestService.isSupported to return true?

We are planning to roll out Apple App Attest for our iOS app and have a question about DCAppAttestService.attestKey(_:clientDataHash:) rate limiting during a large-scale rollout. We understand that attestKey(:clientDataHash:) should be used only during the initial App Attest key registration flow, and that subsequent protected API requests should use generateAssertion(:clientDataHash:). However, during rollout, existing users may gradually register App Attest keys, and we want to avoid causing unnecessary attestation traffic spikes. Could Apple confirm the recommended approach for handling this at scale? Specifically: Is there any supported process to request temporary rate limit accommodation for attestKey calls during a large-scale rollout? If rate limit accommodation is not available, should we rely entirely on staged rollout, exponential backoff, retryAfter handling, and grace-mode handling? Are there any additional recommendations for apps with a large number of daily active users to avoid App Attest attestation rate limiting? Thank you.

Hi, The WWDC session noted App Attest is supported on macOS 27, but only for certain extension types (Action and SSO were the examples shown IIRC). Is there a definitive list of which extension types support DCAppAttestService on macOS 27 — and is the credential-provider extension (ASCredentialProviderExtension) among them? If credential-provider extensions are not supported, in an app that ships a credential-provider extension, can I add a separate (e.g. SSO or Action) extension — or use the containing app — to perform App Attest and generate/attest a key, then use that key from the credential-provider extension (e.g. via a shared keychain access group)? Or is the attested key inherently bound to the attesting process and not shareable? Thanks!

We have an application with multiple extension targets. We generate device check token using DCDevice.current.generateToken API. However while trying to validate the device using devicecheck.apple.com/v1/validate_device_token from our servers, we get success for our extension targets but failure for our app target. The transaction IDs are below For App target's device check token: 26050657-fa98-4d2e-8e28-eb0e4005cf15 For extension target's device check token: cfab83e0-8aa7-43e7-8343-f8baaec6ee651001 We assume this is because our main target has a different APPID prefix compared to our extension targets. Device validation API should not fail because the code signing is done from the same developer ID. Can you check on this? Or Can we use the device verify token from our extension targets for validating the app since extension targets are a bundled with app target by design?

Are there any plans to increase the DC token validity or enable using attestations to set the device check bit states? The current implementation makes it challenging to set bit states once we identify a device as belong to a bad actor after the fact. We need to actor to re-engage with the platform to be able to collect a DC token which mostly doesnt happen since they use burner accounts and move on.

Hi App Attest team, I was nodding along happily in the wwdc session, because it was seeming like an air tight solution to prevent API abuse while allowing "guest" access (e.g. not enforcing that users log in). Then I hit this line, "a compromised device can still pass attestations". How is that possible? Earlier in the session, the presenter said "[AppAttest] gives you the assurance that your app is running on a secure apple device". I'm trying to square these statements and understand the motivation of the 'fraud metric'. Thank you! Lou Ps. I'm so happy that AppAttest is available on Mac now. :D

The wwdc session mentioned that attestation keys survive app updates but not reinstalls. So it seems like if I try to create an assertion after reinstall from the key I pull from keychain, and include that assertion in my API payload to my backend, my backend will reject the assertion. Is there any mechanism for us to ask the client framework "is this key still valid"? Thanks again, Lou

My understanding from the App Attest wwdc session is that we store attestation keys in keychain on a per-user basis. For apps that don't require user login, I'm thinking of using StoreKit's AppTransactionID [1] as the identifier to discriminate keys. Do you have opinions on whether this is a valid pattern? [1] https://developer.apple.com/documentation/storekit/apptransaction/apptransactionid

Apple has provided a number of Swift Packages for backend development, including some new tools for wallet passes! Is there anything like this for attestation and device check capabilities for a swift-on-server product to consume? If not, consider this a placeholder for a future feedback request.

Hi! I have not seen this year's video yet, so please forgive me if this is answered. I notice a couple of folks here saying that AppAttest is (at least partially) supported on macOS 27. Is this correct? My specific use case is a "designed for iPad" app running on macOS. We use App Attest to make high-value requests to our headend services and would really like this to work on macOS as well.

Since device check APIs (attestation) are not available for extensions like share extension and widget extension (at least in 26 and according to documentation still in 27) - is there any best practice how to still protect endpoints which are also called from these extensions? And subquestion: is there a technical limitation in iOS design that made it impossible to also support extensions.