Since these are system libraries, they are linked to your app dynamically. They would be easy to swap out with stubs that would make your app think that a receipt is valid. @johndaniel I was under the impression that, because CryptoKit is a system library, it actually avoids that issue? Despite being dynamically linked, wouldn't the fact that it is integral to the OS mean that for an attacker to swap it out, the OS itself would need to be compromised? Or am I over-extrapolating? I'm trying to wrap my head around all this - so forgive my ignorance.

It appears Apple has updated the documentation on this, explaining that there are a few cases where App Attest may be unsupported: If you read isSupported from an app running on a Mac device, the value is always false. This includes Mac Catalyst apps, and iOS or iPadOS apps running on Apple silicon. If you read isSupported from within an app extension, the value might be true or false, depending on the extension type. However, extensions don’t support App Attest. The generateKey(completionHandler:) method always fails when you call it from an app extension, regardless of the value of isSupported.

@edford This is a huge problem that still exists in Xcode 14 and has been plaguing our team for over a year now. Every. Single. Time. We create a new file or try to rename a file in a local Swift Package. Affects every machine and every developer at our company regardless of Xcode version, macOS version, hardware, etc.

@DTS Engineer Thanks for the forum tips! This is a handy tool to check the status of a profile. Thanks for sharing that bash script. I filed a Feedback FB13513470 on January 3, 2024. I've also added a recent reply to the feedback to "bump" it. Appreciate you looking into this for us!