We've also noticed some errors yesterday (29 June 2023 between ~21:00 and 23:00 UTC). Hope it gets resolved and the service becomes more stable.

Many thanks @eskimo for the very insightful and honest answer. In the latest 30 days the issue affected ~0.05% of our users, it's a fraction of the whole population, but still a significant number. We will try to add some workaround to help users to re-generate and re-enroll the key if we see this issue happening, currently it's treated as a transient error so users can retry, but as you mentioned, it will never work again. Do you have enough data i.e. sysdiagnose reports to debug it? I can help to get more reports. We get info about this issue almost in real time and have infrastructure/processes in place to follow up with users and collect diagnostics (including sysdiagnose) if needed.

Thanks @eskimo, we used to use .biometryCurrentSet (for internal users in the beta phase long before making the app available in AppStore), but stopped when "Face ID with a Mask" was introduced as it was invalidating the enrollments. Current set of flags: let access = SecAccessControlCreateWithFlags( kCFAllocatorDefault,     kSecAttrAccessibleWhenUnlockedThisDeviceOnly,     [.privateKeyUsage, .biometryAny],     nil )

We've encountered the same problem. @spindel, have feedback/DTS helped you find the root cause of the issue and if so do you mind sharing your findings here?

Thank you both. I am aware of DriverKit, however, the tool I am signing is coming from our vendor, and as you can imagine, my influence is slightly limited : ). I will send them a reminder about the future of KEXT in case they've missed it.

It means the user needs to interact with the website via gesture, e.g. touch. It's nicely explained on https://webkit.org/blog/11312/meet-face-id-and-touch-id-for-the-web/. Something like this should work: function login() { // use navigator.credentials.get  } document.addEventListener("DOMContentLoaded", e => { document.querySelector('#login-button').addEventListener('click', login); }

I had CFBundleName set to $(PRODUCT_NAME), but no CFBundleDisplayName as the name inferred by Xcode from the bundle identifier seemed to be enough. I explicitelly set CFBundleDisplayName and now the messaging includes the display name, no more "". Thank you very much!

Hi @mervyn.ong, If I am not mistaken, for security reasons, the file is not accessed or validated by the device, but Apple backend infrastructure (CDN) as such the file must be accessible via the internet. There is a way to temporarily tweak this behaviour by using query parameter ?mode= during development, it's nicely explained in the documentation https://developer.apple.com/documentation/xcode/supporting-associated-domains.

Thanks @KivancG, I was also affected by this issue, your answer helped. Have you submitted a feedback? Xref (probably the same issue) https://developer.apple.com/forums/thread/679098?answerId=673107022

I'm getting the same error. I have CLANG_MODULES_AUTOLINK set to NO, both WatchConnectivity and WatchKit frameworks linked explicitly (the extension is written in Objective-C). Turned out libWKExtensionMainLegacy.a in Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator7.0.sdk supports x86_64, i386, and arm64. $ lipo -archs libWKExtensionMainLegacy.a x86_64 arm64 i386 However, according to the link https://developer.apple.com/forums/thread/130684, the configuration might not be correct. Having x8664 code is not sufficient to distinguish if a binary is intended for the iOS Simulator, a macOS app, or a Mac Catalyst app. Combing built binaries across different destinations (which includes the simulator vs. device binaries) is not a supported combination -- there is no Apple platform where ARM code and x8664 code in the same binary is a correct configuration. Stripping the arm64 from the binary didn't help (just did it for testing, it couldn't be treated as a solution anyway), and got a new warning: Showing Recent Issues Ignoring file .../Xcode12-beta3.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator7.0.sdk/usr/lib/libWKExtensionMainLegacy.a, missing required architecture arm64 in file .../Xcode12-beta3.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator7.0.sdk/usr/lib/libWKExtensionMainLegacy.a (2 slices) and error: Showing Recent Issues In .../Xcode12-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/12.0.0/lib/darwin/libclang_rt.watchos.a(floatditf.c.o), building for watchOS Simulator, but linking in object file (.../Xcode12-beta3.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/12.0.0/lib/darwin/libclang_rt.watchos.a(floatditf.c.o)) built for watchOS, file '.../Xcode12-beta3.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/12.0.0/lib/darwin/libclang_rt.watchos.a' for architecture arm64

The options were not listed in Xcode 11.5 neither. I think it was a deliberate choice to avoid mismatches (with Provisioning Profiles). Xcode might automatically sync this setting with the App Identifier (not sure about the details).

It's probably worth filing a feedback. In the meantime, you can open the .entitlements file in any text editor (luckily it's a plaintext plist file) and check/modify the settings manually (all available options are nicely documented https://developer.apple.com/documentation/foundation/nsfileprotectioncomplete). i.e. <dict> 	 <key>com.apple.developer.default-data-protection</key> 	 <string>NSFileProtectionComplete</string> </dict> Once you have your .ipa file ready for submission, you can also inspect the entitlements by unzipping the .ipa and calling codesign -d --entitlements :- <path_to_app_bundle>

The case is particularly interesting as removing data protection setting from app entitlements plist can help to mitigate issues related to FB6557020 ("Default data protection entitlement keeps getting reverted to Complete whenever we set it Protected Until First User Authentication" [App Store Connect])