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 generate Secure Enclave keys via SecKeyCreateRandomKey with kSecAttrTokenIDSecureEnclave on macOS. We need to prove to a remote server that the key is genuinely hardware-bound, not a software key claiming to be one. Is there any API on macOS for an app to obtain an Apple-signed certificate or attestation statement for such a Secure Enclave key, similar to how ASAuthorizationProviderExtensionLoginManager.attestKey() works within Platform SSO but available to general apps? Or other possible workaround for this? 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.

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.