Permission requirements for LAContext's canEvaluatePolicy

Question

Created Jun ’25

Replies 2

Boosts 0

Participants 2

Hi,

I am developing an app that checks if biometric authentication capabilities (Face ID and Touch ID) are available on a device. I have a few questions:

Do I need to include a privacy string in my app to use the LAContext's canEvaluatePolicy function? This function checks if biometric authentication is available on the device, but does not actually trigger the authentication.

From my testing, it seems like a privacy declaration is only required when using LAContext's evaluatePolicy function, which would trigger the biometric authentication. Can you confirm if this is the expected behavior across all iOS versions and iPhone models?

When exactly does the biometric authentication permission pop-up appear for users - is it when calling canEvaluatePolicy or evaluatePolicy? I want to ensure my users have a seamless experience.

Please let me know if you have any insights on these questions. I want to make sure I'm handling the biometric authentication functionality correctly in my app. Thank you!

Boost

Answer 1

DTS Engineer OP

Apple

Jun ’25

Recommended

I can give you a good answer for this:

When exactly does the biometric authentication permission pop-up appear for users - is it when calling canEvaluatePolicy(…) or evaluatePolicy(…)?

The latter.

The purpose of canEvaluatePolicy(…) is to tell you whether a policy is supported or not. It’s the act of evaluating that policy that triggers side effects, like a biometrics user interaction.

Do I need to include a privacy string in my app to use the LAContext's canEvaluatePolicy(…) function?

Now, that’s a more subtle question. There’s an implicit assumption in the API that folks would only call canEvaluatePolicy(…) because they want to, at some point, evaluate a policy, and that obviously requires a privacy string. It’s easy to imagine the Local Authentication implementation requiring the privacy string in your unusal case. Your tests confirm that the current implementation doesn’t require it, but that could change.

What’s the downside to providing a privacy string, just in case?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1

Answer 2

DTS Engineer OP

Apple

Jun ’25

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits.

If this is the case, there are no downsides to including the privacy string on my end.

Right.

One thing to keep in mind here is that the privacy string is specific to Face ID. If you try to use Face ID without it, that’ll fail. However, it doesn’t apply to Touch ID, and there’s no equivalent privacy string for Touch ID.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0