Posts

Post not yet marked as solved
5 Replies
@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.
Post not yet marked as solved
1 Replies
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.
Post not yet marked as solved
2 Replies
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.