iOS app installation fails with 0xe8008018 for company team, but succeeds with another Apple Account Hello Apple Developer Community, We are facing a persistent code-signing issue while installing iOS development builds on a physical iPhone. We have contacted Apple Developer Support multiple times, but we have not yet received a technical explanation for the root cause. Environment Xcode: 26.6 (Build 17F113) macOS: 26.5.2 (Build 25F84) Device: iPhone 12 Pro Max (iPhone12,5) iOS: 26.5 (Build 23F77) Company Team ID: T6MQ4RXG46 Development certificate: Apple Development: Muthoot Money Limited (3MH4U8W7M5) Error message When installing the app through Xcode, installation fails with: 0xe8008018 — The identity used to sign the executable is no longer valid. The full error also contains: MIInstallerErrorDomain Code=13 CoreDeviceError Code=3002 IXUserPresentableErrorDomain Code=14 ApplicationVerificationFailed Troubleshooting performed Verified that the development certificate is within its validity period. Checked the provisioning profile's expiration date and confirmed that the test device UDID is included. Verified the app signature locally using codesign --verify --deep --strict. Confirmed that the app's signing authority and TeamIdentifier match our company team. Tested both our existing application and a newly created minimal iOS project named SigningTest. Important finding The newly created SigningTest app also fails to install when signed using our company team. However, the same test app installs successfully on the same iPhone when signed using another Apple Account's team. This suggests that the issue may be related to the company team's signing configuration or another team-specific factor, although we have not identified the root cause. Questions What could cause iOS to reject a locally valid app signature with error 0xe8008018? How can we identify the specific certificate, provisioning, trust, or device-verification check that is failing during installation? Is there any additional diagnostic command or device log we should collect? Could this indicate a team-specific signing issue that requires investigation by Apple? We would appreciate any technical guidance from developers who have encountered and resolved the same error. Thank you.

I'm implementing Apple's App Attest service in a Swift iOS app using DCAppAttestService, with a TypeScript backend hosted on Cloudflare Workers. Key generation and attestation registration both work correctly. The server successfully validates Apple's certificate chain, confirms that the public key matches the key ID, and stores the P-256 public key. However, when the app calls generateAssertion, the server consistently fails to verify the returned signature. Here's what I've checked so far: The app passes SHA256(clientData) to generateAssertion, as Apple's documentation requires. The server constructs the verification message using authenticatorData || SHA256(clientData). I've confirmed that the client and server use matching hashes, assertion data, authenticator data, and verification messages. The stored public key matches the App Attest key ID. The returned signature has a valid DER structure. Signature verification fails using both Web Crypto (with DER-to-P1363 conversion) and a separate Node.js verification method. Both verification methods work correctly with independently generated test signatures. Challenge validation, RP ID checks, environment checks, and extension validation all pass. One thing that stands out: The assertion's authenticator data contains the flags 0xC0 (AT + ED). An extension data map appears immediately after the standard 37-byte header, without the credential data that would normally be expected when the AT flag is set. Apple mentioned new App Attest assertion extensions in WWDC26, but I haven't found documentation explaining whether this specific format is expected on iOS 27. My server includes the entire original authenticator data, including the flags and extensions, when verifying the signature. Nothing is removed or modified. I have three questions: Is 0xC0 a valid flag combination for App Attest assertions on iOS 27 when extension data follows the 37-byte header without a separate credential data section? Does the standard signature verification formula, SHA256(authenticatorData || SHA256(clientData)), still apply when these new extensions are present? Are there any known issues or changes in iOS 27 that could cause generateAssertion to succeed while the server cannot verify its signature using the public key obtained during registration? I'm testing on a physical iPhone using a Debug development build, not the simulator. I've also kept the original App Attest key and registration unchanged throughout testing. At this point, the client and server appear to agree on all the data used for verification, but the signature still fails. I'm trying to determine whether I'm missing something about the new assertion format or whether there is another part of the verification process I should investigate. Any guidance would be appreciated.

I’m investigating App Attest sandbox configuration for a native macOS app. Apple DTS suggested asking here. Environment: Physical MacBook running macOS 27.0.1 (26A434) Xcode 27.0 (27A266a) Native SwiftUI macOS application, launched from Xcode in Debug Development signing with a regenerated Mac development provisioning profile The same App ID is used for the iPad and Mac targets Observed behavior: App Attest is enabled for the App ID in the Developer portal. The Mac entitlements source requests: com.apple.developer.devicecheck.appattest-environment = development We tried both a build-setting substitution and the literal development value, regenerated the profile, and rebuilt. The inspected Mac provisioning profile does not contain this entitlement. Xcode’s generated signing entitlements (.xcent) and the signed application also omit it. DCAppAttestService generates a fresh key and returns an attestation successfully. Our development server observes AAGUID 61707061747465737400000000000000 (production) and rejects it because it requires development evidence. The physical iPad development build produces development evidence and enrolls successfully against the same server. Relevant server diagnostic: client App Attest environment mismatch expected_environment=development observed_aaguid=61707061747465737400000000000000 The failure occurs at the environment gate, before certificate/signature verification. I am not claiming that the entire Mac attestation has already passed cryptographic verification. Questions: Is development/sandbox App Attest supported for native macOS 27 apps? If supported, which entitlement and provisioning configuration is required, and why is the requested environment omitted during signing? If production-mode evidence is expected for development-signed Mac apps, what is the recommended server environment policy? Is this a known issue with macOS 27.0.1 or Xcode 27.0? We would like to keep development attestation separate from production while retaining full cryptographic verification and using the same App ID for both platforms. I can provide sanitized entitlement and signing-output excerpts, together with a minimal reproducer. Which diagnostics would help establish why the development entitlement is missing?

Our iPad application uses authenticated accounts in our own service. Before enabling access for a member receiving an assigned subscription, we need to establish that the actual assigned Apple member authorized enrollment into the intended account in our service. The unresolved case is another authenticated application account presenting forwarded, genuinely Apple-signed member transaction or app transaction evidence. We need to understand the supported verification boundary that prevents possession of that evidence from being sufficient to acquire another member's access. Personal purchase ownership will remain separate from assigned-member access. Proposed flow for review: The app obtains AppTransaction and the assigned Transaction directly from StoreKit and checks both against the current device using the documented device-verification procedure. It then proposes an App Attest assertion over the exact evidence and a server-issued challenge associated with the authenticated application account. The proposed client method accepts no forwarded JWS input. Our server would separately authenticate the service session and verify the attestation, assertion, Apple-signed evidence, current assignment and subscription lifecycle before granting access. Is this composition supported for authenticating assigned-member enrollment? Specifically, may the server rely on the direct StoreKit capture and local device checks within the attested app to establish that the same Apple member authorized the intended application-account association? What connects the StoreKit member/device verification, the App Attest key and the intended account, so that a valid assertion over forwarded authentic evidence would not be sufficient? Please identify the required server validation and trust assumptions, or an additional supported API/protocol if the proposal is insufficient. We also need to understand recovery after reinstall or an application-account switch, and the applicable Sandbox, TestFlight and Production support. Matching identifiers or a first successful claim must not transfer another member's access. What we have checked: The StoreKit deviceVerification documentation describes checking whether a transaction belongs to the device. The App Attest server-validation guide describes attestation, assertions, one-time challenges and per-user/device key association. We have not found an explicit assigned-member enrollment contract covering their composition. The closest existing discussions are "Scoping App Attest keys to an appTransactionID" and "Is keying off Storekit's AppTransactionID a valid pattern for storing keys?" They discuss key organization for anonymous users; they do not resolve this assigned-member enrollment question. This is an API and trust-contract clarification. A focused, newly authored sample was supplied privately to DTS. It contains no customer records, credentials, captured transaction evidence or production source. The sample was prepared using Xcode 27.0 on macOS 27.0.1 and targets iOS/iPadOS with the iOS 27 SDK. Swift syntax and project-file parsing passed, but it has not been compiled, signed, installed or device-tested. The default app displays the question; it invokes no StoreKit, App Attest, purchase, enrollment or network calls. We have not enabled assigned-member grants or claimed a reproduced Apple defect. References: https://developer.apple.com/documentation/storekit/transaction/deviceverification https://developer.apple.com/documentation/devicecheck/validating-apps-that-connect-to-your-server https://developer.apple.com/videos/play/wwdc2026/391/ https://developer.apple.com/documentation/appstoreserverapi/get-customer-groups https://developer.apple.com/forums/thread/833174 https://developer.apple.com/forums/thread/831468

I'm building an iOS app (bundle identifier ca.fanforge.pos, Team ID 856C6JT832) that uses a third-party payment SDK to connect to a physical Bluetooth card reader. The SDK requires my app to successfully complete Apple's App Attest process against the production environment before it will allow a real card reader to connect. I have set the entitlement com.apple.developer.devicecheck.appattest-environment to production in my app's entitlements, and I have enabled the App Attest capability on my App ID in the Apple Developer portal. I confirmed directly, by extracting the compiled app binary and running codesign -d --entitlements :- MyApp on it, that the entitlement is present with the value production in the actual signed binary, not just in my source configuration. When I distribute this exact build as an ad-hoc build (a registered test device added to my provisioning profile, not through TestFlight or the App Store), the card reader fails to connect with an error indicating it cannot establish a secure connection to the payment provider's servers. When I distribute the identical app (same version, same entitlements, same provisioning) through TestFlight instead, the card reader connects successfully and I am able to process a real payment. Steps I have already taken to rule out other causes: Verified the payment provider's account credentials are valid and correctly configured for production (confirmed via a direct API call returning a successful response) Verified the App Attest capability is enabled on my App ID in the Apple Developer portal Verified the entitlement value directly in the compiled binary's code signature (not just my source files) Registered the required application signature with the payment provider Fully removed and reinstalled the app between tests Confirmed the reader hardware itself works correctly (it connects successfully in the TestFlight-distributed build) My question: Does ad-hoc distribution have different behavior than documented for the com.apple.developer.devicecheck.appattest-environment entitlement? Apple's documentation states that after distribution through TestFlight, the App Store, or the Apple Developer Enterprise Program, an app automatically uses the production App Attest environment regardless of the entitlement value. It also states that for other distribution methods, the entitlement value itself should directly control which environment is used. My ad-hoc build has the entitlement explicitly set to production, yet its behavior matches what I would expect from the sandbox environment, not production. Expected outcome: I would like to understand whether ad-hoc distribution is expected to correctly honor an explicit production entitlement value for App Attest, or whether there is a known limitation or additional requirement for ad-hoc distribution specifically that isn't covered in the entitlement's documentation.

Hello, Since we enabled App Attest in our production app on Aug 13, 2026, a small subset of users consistently fails attestation with DCError.invalidKey. For multiple confirmed devices the failure appears to be permanent: attestKey rejects even newly generated keys, and reinstalling the app, rebooting the device, or updating the app does not help. Environment Production builds from the App Store, real devices only, production App Attest environment Attestation succeeds for the vast majority of users (about 70,000 keys registered so far) Primary case (user-reported, verified end to end): iPhone XS Max, iOS 17.6.1, region US. 34 invalidKey events since Aug 13; no attestation record on our server; reinstall and reboot did not help Other devices showing the same persistent pattern in our internal logs (each of these reported invalidKey exclusively): iPhone X, iOS 16.7.16: 69 events over 16 days iPhone X (a second device), iOS 16.7.16: 60 events over 17 days iPhone 8, iOS 16.7.16: 12 events over 7 days iPhone XR, iOS 18.7.9: 11 events over 7 days We also see a smaller number of devices failing persistently with unknownSystemFailure instead of invalidKey, for example an iPhone XR on iOS 18.6.2 with 39 events over 15 days In our internal logs, App Attest errors in general appear across a range of iOS versions and devices Implementation flow DCAppAttestService.shared.generateKey attestKey(_:clientDataHash:) with a SHA-256 hash of a server-issued nonce On failure we retry up to 3 times, with backoff intervals of 0.5, 1, and 2 seconds. For DCError.invalidKey, each retry discards the previous key and generates a brand-new key before calling attestKey again; for serverUnavailable we retry with the same key and clientDataHash, per the DCError header guidance Error characteristics For the affected device, all 3 attempts fail with DCError.invalidKey (com.apple.devicecheck.error code 3), even though every attempt uses a newly generated key ID The failure has persisted continuously since Aug 13, 2026 (19 days and ongoing at the time of writing) App reinstall and device reboot do not resolve it, and the failure has persisted across three consecutive app versions Our server has no attestation record for this user at all, so the key has never been successfully attested; this is not a case of a stale or previously attested key being reused The device supports App Attest. For some users of our sibling app in Japan the same error was transient: they hit invalidKey and then attested successfully later, so invalidKey is clearly transient in some cases but appears permanent in others Scale Our internal logs show 478 attestation-failure events from 61 users between Aug 13 and Sep 1, across all DCError codes Of those, at least 298 events from 30 users are invalidKey, roughly 0.01 percent of our active users (about 360,000) What we have ruled out Key reuse: every retry generates a fresh key clientDataHash handling: identical code succeeds for 99.99 percent of users Server-side verification: the failure happens client-side in attestKey, before our server is ever contacted Account state: the affected user is in good standing Questions Under what conditions can attestKey return invalidKey for a freshly generated key? The documentation describes invalidKey as an invalid key identifier, but here the key ID comes directly from a just-completed generateKey call. Is there any known device-side or Apple-server-side state that can cause a specific device to fail attestation persistently (for weeks, across reinstalls and reboots)? If so, is there anything the user or we can do to remediate it? Is there a recommended way to distinguish between a transient failure, a permanent device-level failure, and an Apple-side service issue, or to get more diagnostics for these failures in production? The NSError carries no information beyond the DCError code, which does not seem to differentiate these cases. Is the guidance from earlier threads (for example thread 812308) still current, that is: should we treat a device that persistently fails attestation as if App Attest were unsupported and fall back accordingly? We are hesitant because that fallback becomes an obvious bypass path for bad actors. Could this be related to throttling or rate limiting of attestKey? Our retries are capped at 3 attempts per verification flow, with 0.5 to 2 second backoff. Any insight would be greatly appreciated. Thank you.

I’m implementing server-side App Attest validation and trying to verify my implementation against Apple’s published Attestation Object Validation Guide sample. I have already filed Feedback Assistant report FB24281098. Using only the values published in Apple’s sample, I can reproduce four apparent inconsistencies: Nonce calculation The documented procedure says to compute: clientDataHash = SHA256(clientData) and then: nonce = SHA256(authenticatorData || clientDataHash) Using the published server challenge, this produces: 1d1ce78912897de88cfe9fce5521aab37abfb09dc544833ff115612552cf75f3 However, the nonce contained in the sample certificate / published expected nonce is: 87b7d06d93a4294e46f011e66b6cc400f0bab20729976c619580b42ae60bff6e That value is reproduced when the raw challenge is appended to authenticatorData instead of SHA256(challenge). The block labeled “Expected clientDataHash” also appears substantially longer than a 32-byte SHA-256 digest. Public-key hash / key ID SHA256 of the leaf certificate’s X9.62 uncompressed P-256 public key is: ce0498f58483fbb4da0d7b2c63a5a538f552d4adcb9a4fa916195c49613e655d This matches the decoded key ID / credential ID from the attestation object. However, the separately published expected public-key hash is: 8a71a32b625b68012102c6300a7b36cd3c990f3b09dce2b1dd0da79f193e9a46 which appears to be SHA256 of the key-ID bytes instead. Bundle version The sample certificate extension contains the value "1", while the guide prose describes "1.0". Validation category The sample extension contains four bytes 01 00 00 00, while the guide describes the value as UInt32 category 1. I’m looking for clarification on the authoritative wire representation / parsing rule. Could Apple please confirm the authoritative byte-level behavior for these four fields, particularly: whether the nonce must use SHA256(clientData) as documented; whether the key ID must equal SHA256 of the X9.62 uncompressed public key; the exact bundle-version comparison rule; and the canonical validation-category representation? I’m intentionally avoiding accepting multiple interpretations or adding fallback behavior in a security-sensitive server verifier, so clarification from Apple would be greatly appreciated.

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.

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.

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!

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?

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.

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.

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.

Hi there, We're implementing Apple's DeviceCheck App Attest for production iOS authentication. The public documentation defines DCError cases but doesn't specify which errors are expected per API method or recommend retry/remediation strategies. We need Apple's guidance to implement robust, production-aligned error handling before rollout. 1. Error Surface per API Method Question: Can you confirm the complete, officially expected set of DCError values for each method? We understand the following errors are possible across App Attest APIs: invalidKey invalidInput featureUnsupported serverUnavailable unknownSystemFailure Specifically, please confirm which errors can occur for: DCAppAttestService.generateKey() DCAppAttestService.attestKey(_:clientData:) DCAppAttestService.generateAssertion(keyID:clientData:) Are there any additional undocumented or edge-case errors we should handle? 2. Retry Strategy & Remediation Matrix Question: For each API method and error code, please help us with proposal around which errorCode is retriable, whats the remediation pre retry, retry cap and backoff strategy: Kindly also help with errors that are not covered here: Specific sub-questions: invalidKey handling: When this error occurs: Should the app delete the key and call generateKey again? Or should it fail the entire flow? serverUnavailable handling: Should we retry immediately, or wait before retrying? Is exponential backoff recommended? What's the recommended max retry count? Backoff strategy: Which errors (if any) qualify for exponential backoff? Recommended base delay, max delay, and jitter approach? When should we give up and fail the request? unknownSystemFailure: Is this retriable or should we fail? Any known causes or mitigations? 3. Simulator Testing Questions: Simulator API behavior: Can App Attest APIs be called normally on iOS Simulator? If not, is there a way to simulate for testing. Do they complete successfully with simulated attestations, or do they fail? Thanks, Nirekshitha

I'm currently reviewing the various DCError cases defined in Apple’s DeviceCheck framework (reference: https://developer.apple.com/documentation/devicecheck/dcerror-swift.struct). To better understand how to handle these in production, I’m looking for a clear breakdown of: Which specific DCError values can occur during service.generateKey, service.attestKey, and service.generateAssertion The realworld scenarios or conditions that typically cause each error for each method. If anyone has insight on how these errors arise and what conditions trigger them, I’d appreciate your input.

I'm trying to confirm the correct URL for Apple Attest development. There seems to be a fraud metric risk section that uses this: https://data-development.appattest.apple.com/v1/attestationData However the key verification seems to use this: https://data-development.appattest.apple.com/v1/attestation Currently I'm attempting to verify the key, so the second one seems likely. However I keep receiving a 404 despite vigorous validation of all fields included in the JSON as well as headers. Can anyone confirm please, which URL I should be sending my AppleAttestationRequest to?

I’m looking for clarification on how rate limiting works for the App Attest service, especially in production environments. According to the entitlement documentation (https://developer.apple.com/documentation/BundleResources/Entitlements/com.apple.developer.devicecheck.appattest-environment), iOS ignores the environment setting once an app is distributed through TestFlight, the App Store, or Enterprise distribution, and always contacts the production App Attest endpoint. With that context, I have two questions: Rate‑Limiting Thresholds How exactly does rate limiting work for App Attest? Is there a defined threshold beyond which attestation requests begin to fail? The "Preparing to Use the App Attest Service" documentation (https://developer.apple.com/documentation/devicecheck/preparing-to-use-the-app-attest-service) recommends ramping up no more than 10 million users per day per app, but I’m trying to understand what practical limits or failure conditions developers should expect. Per‑AppID Budgeting If multiple apps have different App IDs, do they each receive their own independent attestation budget/rate limit? Or is the rate limiting shared across all apps under the same developer account?

From watching the video on App Attest the answer would appear to be no, but the video is a few years old so in hope, I thought I would post this question anyway. There's several scenarios where I would like a notification service extension to be able to use App Attest in communications with the back end(for example to send a receipt to the backend acknowledging receipt of the push, fetching an image from a url in the push payload, a few others). Any change App Attest can be used in by a notification service extension?

Is there a way to check your app signature to verify if any one has tampered with the ipa file. I want to know specifically how to determine and handle this type of situation. How can i do a check for this in code(swift).