Crash on launching with Face ID support on iPhone X, iOS 11.4
mgod opened this issue · 8 comments
This isn't a bug in the library, but you are now required to add a NSFaceIDUsageDescription with some string value if you support Face ID for your passcode unlock. I'm not sure if there's a way to check the plist for this value at runtime and avoid initiating Face ID if it's missing, but the docs should probably be updated and I'm leaving this here for others to reference.
To reproduce the issue:
- Launch an iPhone X or iPhone X simulator on iOS 11.4 with Face ID enabled and with faces enrolled
- Add a passcode to your app with biometric support enabled
- Re-launch the app to trigger the passcode lock
- You should get a crash at this point instead of a Face ID prompt.
Apple docs are here and suggest this has been required since iOS 11.0: https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW75
Hey, @mgod,
Thanks for the heads-up. I consider that if you intentionally activate Face ID, you should also be aware that you need to update your Info.plist, but I will update the documentation, since that's a good idea.
Thanks @rolandleth! I really appreciate the library. It looks like it would also be fairly straightforward to check if the NSFaceIDUsageDescription string exists when the setAllowUnlockWithBiometrics method gets called with true and either log a warning message or throw an error if it's missing. Would you be interested in a PR that does either of these?
There doesn't seem to be an easy check to not use Face ID if the string is missing when it's asked for to unlock.
Glad you like it!
I'm not sure it will actually help: if a user will trigger that error and see they have to fix something, then they'd run that code anyway and crash the app; if a user doesn't reach the point where the app crashes, they wouldn't reach the point where the error is thrown, either. Me thinks.
Hmmm, true. I was more thinking that by including a logging line with a warning, you might get the attention of the developer when they're building the feature.
Aye, that would make it obvious, but that would also make it permanent, even if you took care of it/didn't implement that part 😞
True. I'll just leave a note here then for future confused developer searches that if you fail to do this you'll get some error logging that includes something like:
__TCCAccessRequest_block_invoke.85 + 202
__CRASHING_DUE_TO_PRIVACY_VIOLATION__ + 706
Cool, thanks!