Anyone knows any specific reason for the non-rollout of iOS 27 beta versions in APAC specifically India. i will be much obliged for any illumination from informed community.

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.