Hi, iOS 15.4 is bringing a new exciting security feature which allows users to enroll "masked face" so they can unlock their devices while wearing a mask. Some apps might leverage evaluatedPolicyDomainState (https://developer.apple.com/documentation/localauthentication/lacontext/1514150-evaluatedpolicydomainstate) to detect if the biometric state has changed, and if so, logging out/locking the user to protect their data. Looks like the masked-face enrolment changes the policy domain state as such it might lead to many unexpected logouts. Is there any way to detect if the change to the state was introduced by the masked face enrollment as such we can somehow retain the user's login session? Many thanks!

Hi, I'd to re-sign an app with an embedded kernel extension. The primary reason for it is that the author of the extension has not signed the binary with timestamp ("The signature does not include a secure timestamp.") as such the app fails the notarisation process. Sadly, I cannot find any way in the Developer Program admin panel to generate a certificate with kernel extensions support. What's the process of generating this certificate? Many thanks for help

Hi, Currently, Passkeys/WebAuthn API is behind a feature toggle. In iOS, turn on the Syncing Platform Authenticator switch under Settings > Developer. The Developer menu is available on your device when you set it up as a development device in Xcode. Is this API going to be enabled by default in the official iOS 15 release?

Hi, I've been recently testing the new WebAuthn support in ASAuthorizationController. I've noticed a small UI inconvenience in my app. The biometric modal displayed on assert request shows: Do you want to sign to "" as "marcin"? or Choose an account to sign in to "". when having more than one key enrolled. Looks like the relyingPartyIdentifier is not used. Is there any other property I should set to ensure the message contains the right service identifier? Many thanks!

Hi, I'm playing with the new improvements to the ASAuthorizationController allowing to leverage WebAuthn API (e.g. ASAuthorizationPlatformPublicKeyCredentialRegistration and ASAuthorizationPlatformPublicKeyCredentialAssertion). I've spotted an odd behaviour when validating assert requests. Here is a small snippet of what's happening in my app: // requesting assertion         let publicKeyCredentialProvider = ASAuthorizationPlatformPublicKeyCredentialProvider(             relyingPartyIdentifier: response.rp.id         )         let assertionRequest = publicKeyCredentialProvider.createCredentialAssertionRequest(challenge: response.challenge) ... // in delegate `assertRequest` is being sent to the server             let assertRequest = AssertRequest(                 user: user,                 signature: credentialAssertion.signature,                 authData: credentialAssertion.rawAuthenticatorData,                 clientData: credentialAssertion.rawClientDataJSON,                 userId: credentialAssertion.userID             ) According to "5.1.4 Use an Existing Credential to Make an Assertion - PublicKeyCredential’s [[Get]] Method" of the WebAuthn spec, the ClientData field should contain type "webauthn.get", but looks it always has "webauthn.create" value and fails my validation. Has anyone else experienced similar issue? I was testing my app on the latest Xcode 13 beta2 and running the app on iOS 15 beta2.

I'd like to better understand the behaviour of entitlements, and default data protection specificially. My assumption is that iOS application does not need to specify default data protection explicitly, neither in Provisioning Profiles or app entitlements plist file. In that case, the default value "Complete until first user authentication. (Default)" will be used (https://developer.apple.com/documentation/uikit/protecting_the_user_s_privacy/encrypting_your_app_s_files). I wonder what happens when the default data protection is specified in PP entitlements with the value "Complete", but the default data protection setting is not present in app entitlements plist at all. My observation is that app entitlements plist is used as a primary source, and validated against PP entitlements, in that case, the binary (codesign -d --entitlements :- <path_to_app>) will NOT have this setting, and frashly installed app will default to "Complete until first user authentication". Side note: I've also noticed the codesign will fail if PP and app entitlements plist have different default-data-protection settings i.e. NSFileProtectionComplete in one, and NSFileProtectionCompleteUntilFirstUserAuthentication in the other (error: Provisioning profile "...” doesn’t match the entitlements). Is it correct to say that if an app does not have default-data-protection setting in its entitlements plist, it's safe assume it will always default to NSFileProtectionCompleteUntilFirstUserAuthentication regardless of the value in Provisioning Profile and App Identifier, i.e. even the Provisioning Profile and App Identifier has Data Protection "Complete", "Protected Unless Open", or "Protected Until First User Authentication", the app will default to NSFileProtectionCompleteUntilFirstUserAuthentication. Many thanks for any tips!

In Xcode 10 I was able to get detailed coverage data by using `xccov` tool by calling:- `xcrun xccov view --file-list` - to get all the paths to sources files- `xcrun xccov view --file <path_to_source_file> <path_to_xcresult>` - to get line coverage data for the given file.Looks like in Xcode 11 we should be able to get the same level of details by using `xcrun xccov view --report --files-for-target` and `xcrun xccov view --report --functions-for-file` but it does not work that way.First issue I expirienced is mangled swift method names. When the `xcresult` file is created while running xcodebuild, the functions names are mangled. Name Coverage ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -------------- CodeCoverageDemo.app 47.46% (28/59) /Users/miwanicki1/TestProjects/CodeCoverageDemo/CodeCoverageDemo/SceneDelegate.swift 34.48% (10/29) $s16CodeCoverageDemo13SceneDelegateC5scene_13willConnectTo7optionsySo7UISceneC_So0K7SessionCSo0K17ConnectionOptionsCtF 100.00% (6/6) $s16CodeCoverageDemo13SceneDelegateC18sceneDidDisconnectyySo7UISceneCF 0.00% (0/6Surprisingly, the issue does not occure when the tests are run in the Xcode.Second issue is that when using the new xccov with `--report`, I do not get the line-level coverage for an idividual source file. `--files-for-target` seems to return only an overview of the function coverage without enumerating the lines and branches.2019-10-15 11:55:38.950 xccov[19041:170343] Requested but did not find extension point with identifier Xcode.IDEFoundation.IDEResultKitSerializationConverter /Users/miwanicki1/TestProjects/CodeCoverageDemo/CodeCoverageDemo/MathDemo.swift: ID Name Range Coverage -- ----------------------------------------------- ------- ------------ 0 $s16CodeCoverageDemo04MathC0C3addyS2i_SitF {5, 6} 83.33% (5/6) 1 $s16CodeCoverageDemo04MathC0C5minusyS2i_SitF {12, 3} 0.00% (0/3) 2 $s16CodeCoverageDemo04MathC0C8multipleyS2i_SitF {16, 3} 0.00% (0/3)Anyone had similar problems? What's the recommended way to get the line-level parsable coverage report similar to the format below where 1 means the lines was executed once, 0 the line wasn't executed.1| func add(_ a: Int, _ b: Int) -> Int { 1| if a < 10 { 1| return a + b 1| } 0| if a == 20 { 0| return 1 0| } 0| if a == 30 { 0| return 2 0| } 0| 0| return a + 2 * b 1| }