Hi, I’m currently implementing App Attest attestation validation on the development server. However, I’m receiving a 403 Forbidden response when I POST a CBOR-encoded payload to the following endpoint: curl -X POST -H "Content-Type: application/cbor" --data-binary @payload.cbor 'https://data-development.appattest.apple.com' Here’s how I’m generating the CBOR payload in Java: Map<String, Object> payload = new HashMap<>(); payload.put("attestation", attestationBytes); // byte[] from DCAppAttestService payload.put("clientDataHash", clientDataHash); // SHA-256 hash of the challenge (byte[]) payload.put("keyId", keyIdBytes); // Base64-decoded keyId (byte[]) payload.put("appId", TEAM_ID + "." + BUNDLE_ID); // e.g., "ABCDE12345.com.example.app" ObjectMapper cborMapper = new ObjectMapper(new CBORFactory()); byte[] cborBody = cborMapper.writeValueAsBytes(payload); I’m unsure whether the endpoint is rejecting the payload format or if the endpoint itself is incorrect for this stage. I’d appreciate clarification on the following: 1. Is https://data-development.appattest.apple.com the correct endpoint for key attestation in a development environment? 2. Should this endpoint accept CBOR-encoded payloads, or is it only for JSON-based assertion validation? 3. Is there a current official Apple documentation that lists: • the correct URLs for key attestation and assertion validation (production and development), • or any server-side example code (e.g., Java, Python) for handling attestation/validation on the backend? So far, I couldn’t find an official document that explicitly describes the expected HTTP endpoints for these operations. If there’s a newer guide or updated API reference, I’d appreciate a link. Thanks in advance for your help.

Hello, We are working on integrating app integrity verification into our service application, following Apple's App Attest and DeviceCheck guide. Our server issues a challenge to the client, which then sends the challenge, attestation, and keyId in CBOR format to Apple's App Attest server for verification. However, we are unable to reach both https://attest.apple.com and https://attest.development.apple.com due to network issues. These attempts have been made from both our internal corporate network and mobile hotspot environments. Despite adjusting DNS settings and other configurations, the issue persists. Are there alternative methods or solutions to address this problem? Any recommended network configurations or guidelines to successfully connect to Apple's App Attest servers would be greatly appreciated. Thank you.

Hello, We are working on integrating app integrity verification into our service application, following Apple's App Attest and DeviceCheck guide. Our server issues a challenge to the client, which then sends the challenge, attestation, and keyId in CBOR format to Apple's App Attest server for verification. However, we are unable to reach both https://attest.apple.com and https://attest.development.apple.com due to network issues. These attempts have been made from both our internal corporate network and mobile hotspot environments. Despite adjusting DNS settings and other configurations, the issue persists. Are there alternative methods or solutions to address this problem? Any recommended network configurations or guidelines to successfully connect to Apple's App Attest servers would be greatly appreciated. Thank you.

I'm a bit confused about if using App Attest is possible in enterprise builds. It shows up under identifiers in the apple dev portal and I can add it to my provisioning file and entitlements file. But if I go to keys I cannot create a key for it. This page implies it can be used for enterprise builds: After distributing your app through TestFlight, the App Store, or the Apple Developer Enterprise Program, your app ignores the entitlement you set and uses the production environment.

Hi, We're in the process of implementing Apple's App Integrity, but am getting stalled due to missing documents. Can anyone assist with this? We've been following https://developer.apple.com/documentation/devicecheck/validating-apps-that-connect-to-your-server to make the necessary updates, but have come up short with where the document references decoding the Attestation Object. Can we get more information here and how the decoding process work?

We recently deployed Attestation on our application, and for a majority of the 40,000 users it works well. We have about six customers who are failing attestation. In digging through debug logs, we're seeing this error "iOS assertion verification failed. Unauthorized access attempted." We're assuming that the UUID is blocked somehow on Apple side but we're stumped as to why. We had a customer come in and we could look at the phone, and best we can tell it's just a generic phone with no jailbroken or any malicious apps. How can we determine if the UUID is blocked?

Hi, For some reason all implemented (and working before) App Attest code has stopped working. iOS is unable to get attestation returning "Operations could not be completed. (com.apple.devicecheck.error error 4.) (serverUnavailable)" On https://developer.apple.com/system-status/ I can see green dot but I suspect that infrastructure is not OK. This is happening with multiple of our apps in multiple geographical regions. Can anyone confirm these problems or know whether it is strictly connected to App Attest service availability?

I tried to send it on the nodejs server I built. No success received 200 My work steps are as follows: The app executes “DCAppAttestService.shared.attestKey” to get receiptData from the acquired attestation. The app sends "receiptData.base64EncodedString()" to the server (code-1) Nodejs code (code-2) Because the app has been uploaded to TestFlight, I set the server IP to "data.appattest.apple.com" Is there something wrong with my steps? code-1 public func attestData(receipt:Data) { if DCDevice.current.isSupported { let sesh = URLSession(configuration: .default) var req = URLRequest(url: URL(string: "http://10.254.239.27:3000/attestationData")!) print(req) req.addValue("application/json", forHTTPHeaderField: "Content-Type") req.httpMethod = "POST" let data = try! JSONSerialization.data(withJSONObject: ["receipt": receipt.base64EncodedString()], options: []) req.httpBody = data let task = sesh.dataTask(with: req, completionHandler: { (data, response, error) in if let data = data, let jsonString = String(data: data, encoding: .utf8) { print(jsonString) } }) task.resume() } else { print("Platform is not supported. Make sure you aren't running in an emulator.") //self.stopActivity() } } code-2 versionRouter.post('/attestationData', function(req, response) { console.log("\n\n\n\n\n"); console.log("receiptApi"); var receiptBase64 = req.body.receipt; if (!receiptBase64) { return response.status(400).send({ error: 'Missing receipt data' }); } let binaryReceipt; if (typeof receiptBase64 === 'string') { const cleaned = receiptBase64.trim(); binaryReceipt = Buffer.from(cleaned, 'base64'); } if (Buffer.isBuffer(binaryReceipt)) { //binaryReceipt = receiptBase64; console.log("receipt is base64 或 Buffer: "+ Buffer.isBuffer(binaryReceipt)); } else { console.error('⚠️ receipt is not base64 or Buffer'); response.status(400).send("Receipt format error"); return; } var jwToken = jwt.sign({}, cert, { algorithm: 'ES256',header: { typ: undefined }, issuer: teamId, keyid: keyId}); var post_options = { host: 'data.appattest.apple.com', port: '443', path: '/v1/attestationData', method: 'POST', headers: { 'Authorization': jwToken, 'Content-Type': 'application/octet-stream', 'Content-Length': binaryReceipt.length } }; var post_req = https.request(post_options, function(res) { res.setEncoding('utf8'); console.log("📨 Apple Response Header:", res.headers); console.log("📨 Apple StatusCode:", res.statusCode); var data = ""; res.on('data', function (chunk) { data += chunk; }); res.on('end', function() { console.log(data); response.send({"status": res.statusCode, data: data}); }); }); post_req.on('error', function(e) { console.error('error:', e); response.status(500).send({ error: e.message }); }); post_req.write(binaryReceipt); post_req.end(); });

Hello, Preparing to use the app attest service documentation suggests we call attestKey(_:clientDataHash:completionHandler:) fewer than 100 requests per second. I had a question - Our app might theoretically hit this limit on launch. Would Apple be able to relax these limits or is this a hard limit?

Hi everyone, We are using the App Attest API to securely transition users to our new system. As part of this, we store the Key ID of the attestation key for each user to verify their identity later. However, we’ve noticed that some users are encountering the error “DCErrorInvalidKey 3” when calling generateAssertion. Importantly, the key was previously successfully attested, and generateAssertion has worked before for these users. Our questions: Could this error be caused by an app or iOS update? Is it problematic to link an attestation key's Key ID directly to a user, or are there scenarios where the key might change or become invalid? If there’s a way to mitigate this issue or recover affected users, what best practices would you recommend? Any help or shared experiences would be greatly appreciated! Thanks in advance.