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.

Hi, Is there a default timeout for the attestKey method? From doc: If the method’s completion handler returns the serverUnavailable error — typically due to network connectivity issues — it means that the framework failed to reach the App Attest service to complete the attestation Br, Johan

We see appAttest (available iOS 14+) provides us 3 key features: if app instance is not modified, device is genuine apple device and payload is not tempered with. We also have deviceCheck Api (iOS 11+) which return 2 bits per device, as mentioned in documentation we can create different payloads for validation and different for updating the 2 bits. Apart from returning those bits in validation request, does this DeviceCheck APIs also validate 2 of the 3 above features i.e. app is not modified and the device is genuine apple device? If yes, what response from apple server to look for in successful validation of above 2 features and what response to look for in fraud cases or failure cases? Does isSupported in case of DCDevice.current hints the device is a simulator ? Can we get exhaustive list of cases where isSupported is false? Does DCDevice.current.generateToken fails only in case of modified app instance? Can we get exhaustive list of cases where above can throw error? Can modified app instance also able to generateToken?

Apple team, I need your help. Can you answer for my question in thread: https://developer.apple.com/forums/thread/701876 ? I created new thread due to I wasn't able to add tag wwdc21-10244 in thread 701876.

Hi there, I wonder what are some common reasons for the Order ID to be in valid... (Other than fake, randomly generated Order IDs, of course.) I have a customer sending me a receipt of a non-consumable item, but when I tried to look up the order using https://api.storekit.itunes.apple.com/inApps/v1/lookup/{order-id}, the response code is 1, indicating the Order ID is invalid. I was able to use the same method to fetch one of my own purchases (because what indie app dev doesn't buy their own stuff?) so I believe the method to look up by Order ID is tried and true. It doesn't seem like the user was faking a screenshot of the order. On the receipt screenshot, the customer purchased the item using Store Credits. Is it likely that the transaction was later marked as fraudulent by Apple, and therefore invalid? Just seeing if anyone has info on this. Thanks!

Hello, We detected some fraudulent activity in one of my app. The user purchases the in-app product, makes use of the service, and then returns it immediately. And he repeats this process every day. We have done some actions to prevent this, but this process continues by using clone app creators. How is the return process going, is there no control in this regard? Normally, if a user buys the same product for the second time, I think that he should not return it anymore.

Hello, I am currently learning about how App Attest works and there are a few things I don't understand. First of all for the certificates of the attestation provided by Apple. Once verified, they attest that the associated customer has a genuine Apple device. What is meant by a genuine Apple device, a non-jailbroken device or simply a device that was produced by Apple? In addition I do not see how these certificates work, how they attest to the authenticity of the device, what they contain? Then regarding the appId, is it kept in the Secure Enclave? Because if not, a super-user could very well modify the application and then go and modify the appId to put back the original. Also, can a user use the AppAttest API without going through my application, in order to produce false certificates for example. Regarding assertion formation for requests, let's imagine that the user does not have a login. The query may possibly be stored on the device in the meantime, will the assertion have already been bound or not? Finally, since the key pair does not survive the reinstallation of the application. Is there any way to block a device that is suspected of having fraudulent activity? Thank you for your attention!