Getting Touch ID notification if passcode is used

Question

I am using Touch ID in my app.

• If Touch ID fingerprint scanning fails three times in a row, I get a Application retry limit exceeded. error.
• If Touch ID fingerprint scanning fails another two times, I get a Biometry is locked out. error.

After being locked out from biometry, you need to enter your passcode. Strangely, if your passcode is entered correctly then this does not lead to a success in the evaluatePolicy callback. Instead, you are then prompted to retry your biometry.

How can I get a notification that the passcode was correctly entered after being locked out of biometry?

Answer 1

A really good way to get used to what I'm mentioning is to use this project Apple has provided: Using Touch ID with Keychain and LocalAuthentication

There are two ways to prompt your user for Touch ID authentication; each have their pros and cons.

1. -[LAContext evaluatePolicy:localizedReason:reply:].

This allows you to prompt the system to ask the user only for their Touch ID authentication (if it is setup correctly). If the user is locked out due to repeated failures either here or somewhere else, they are asked to enter their passcode as a way to unlock Touch ID use again (as far as I can tell). Since the initial goal of calling evaluatePolicy:localizedReason:reply: was to get the user to authenticate with Touch ID, it will still ask them to do it.

The bonus of this approach is the error that you get back from the call is more descriptive about what happened (user canceling vs failed).

2. Store something in the keychain secured by kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly

This option might give you the experience you're interested in. After storing something in the keychain using this attribute, attempting to copy it from the keychain will present the more familiar Touch ID prompt that allows the user to enter their passcode if desired (though I've noticed in the iOS 8.3 Beta, the prompt does not show the "Enter passcode" option on the first attempt.

The downside of this approach is that you always get a failed error, regardless of how the user ended the process (failing in some way or just hitting cancel).