@DTS Engineer I am not the OP but am experiencing the same. dwarfdump --verify returned No errors. (after a bunch of Verifying... lines)

Did you ever figure it out? Xcode text editor is particularly bad for us also

Does anyone have any solutions? For me it is specifically the Swift code editor that is choking on large-ish files, and the exact same code was totally fine under Xcode 13. It has gotten so bad that I just edit the code via VS Code instead of Xcode now :(

Same issue on Ventura 13.2. My FB number is FB11969934

I have the same issue with macOS Moneterey 12.6 and Xcode 14.2 (14C18) (also Xcode 13 had the same but I don't have the build number as I upgraded to Xcode 14.2).

This is actually interesting for us. With our iPad app compiled with iOS 15 SDK and targeting iOS 14+ with 'UIRequiresFullScreen' set in the Info.plist, the app opens and resizes in the Stage Manager but it is not layed out correctly, it seems the OS is doing some scaling so the UI appears stretched.

We're facing the same issue, any ideas?

For iOS it is any device with Secure Enclave running iOS 14.

What is meant by a genuine Apple device -> that means the device has a certificate signed by a CA that chains up to Apple's App Attest Root CA. The appId is stored in your certificate and in each assertion. Super user can modify app id all he wants, he can't modify it in the certificate where Apple put it in on their (Apple's) servers. can a user use the AppAttest API without going through my application, in order to produce false certificates for example - the premise is that Apple keeps their Root CA private keys secure. If those were ever to be compromised then the answer would be yes. However, if that were to happen there would be much bigger issues all up. Regarding assertion formation for requests, let's imagine that the user does not have a login -> if the user does not have a login, don't generate said assertion? it's pretty simple. Is there any way to block a device that is suspected of having fraudulent activity -> that implementation detail is entirely up to your application code.

So I doubt Apple will ever disclose this implementation detail of their proprietary hardware. However, the general overview is provided here: https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_secure_enclave I would guess that they use some sort of Cryptographically secure pseudo random function to generate the EC curve points and would not use any hardware identifiers nor other keys to generate the points.

Which crypto library are you using on node side? Note that Apple's signature comes back ASN.1 Encoded as a Sequence of two integers, and the integers are positive big ints meaning they may have a leading 0x0 byte appended to them. In some frameworks (e.g. .Net) they expect a r|s signature format so you have to extract r and s out of the sequence sent by the device, remove leading 0x0 bytes if present and feed that to your crypto framework.