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.