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.
Post not yet marked as solved
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!
Post not yet marked as solved
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.
Post not yet marked as solved
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
Post not yet marked as solved
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
Post not yet marked as solved
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).
Post not yet marked as solved
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>
Post not yet marked as solved
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])
Post not yet marked as solved
Hi @davidtrax,Latest beta Version 11.2 beta 2 (11B44) seems to resolve the issues (both symbolication and line-level report). Line-level coverage can be pulled via:xccov view --archive [--file-list | --file <path>] result_bundle.xcresultEverything seems to work fine, at least in my small test project.
Post not yet marked as solved
Many thanks for the quick response. Happy to share more context but I'm not sure what function you refer to, we don't call CFReadStreamRead directly. I cannot find anything related in the strack trace. We use pretty much vanila URLSession setup as well as a raw socket connection using `CFStreamCreatePairWithSocketToHost`, `CFNetworkCopyProxiesForAutoConfigurationScript` and few other CF* synchronous functions. Could you point me what kind of API/misuse would cause this type of issue?
