Repository navigation
Crash on launching with Face ID support on iPhone X, iOS 11.4 #193
Description
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.
Activity
mgod commentedon Jun 19, 2018
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
rolandleth commentedon Jun 20, 2018
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.mgod commentedon Jun 21, 2018
Thanks @rolandleth! I really appreciate the library. It looks like it would also be fairly straightforward to check if the
NSFaceIDUsageDescriptionstring exists when thesetAllowUnlockWithBiometricsmethod gets called withtrueand 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.
rolandleth commentedon Jun 21, 2018
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.
mgod commentedon Jun 21, 2018
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.
rolandleth commentedon Jun 21, 2018
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 😞
mgod commentedon Jun 21, 2018
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:
rolandleth commentedon Jun 21, 2018
Cool, thanks!