To add biometric login to an app you unlock a credential you already have.

What the sensor actually proves

Apple states the boundary plainly. The Local Authentication framework hands the comparison to the Secure Enclave, a hardware security processor isolated from the rest of the system, and your app is never given the underlying authentication data. There is no fingerprint image for your code to read. You pick a policy, you supply the sentence the system shows the user explaining why you are asking, and what comes back is a boolean: it worked or it did not. That boolean is the entire output of the feature.

Android draws the same line with the BiometricPrompt dialog from the Biometric library, and adds a distinction worth knowing about. Sensors are graded. BIOMETRIC_STRONG is a Class 3 sensor and BIOMETRIC_WEAK is a Class 2 sensor, as defined in the Android compatibility definition, and DEVICE_CREDENTIAL means the screen lock PIN, pattern or password instead. A cheap face unlock can be Class 2. If the gate guards anything valuable, ask for a strong authenticator rather than accepting whatever the handset offers, and decide deliberately whether the screen lock counts as a pass.

The second limit trips up more projects than the first, and it is not technical. Biometric enrolment belongs to the phone, not to your app. Anyone whose face or finger is enrolled on that device opens your app, and on a shared tablet that is several people. Your code cannot tell which of them it was, because it only ever sees the boolean. If your app holds something exactly one person should see, a biometric gate on its own is the wrong control.

Apple, Local Authentication framework documentation

The pattern: a token in the keychain, biometry on the door

Here is the shape that works. The user signs in once the ordinary way, with a password or an emailed code, and your server returns a refresh token. You write that token into the iOS keychain or the Android keystore with an access control setting that requires biometry before the item can be read. On the next launch you run the biometric check, read the token back, and exchange it for a session. The sensor is not authenticating anyone. It is the key to a drawer, and the drawer holds something your server issued and can take back.

That one decision separates a real feature from a screen saver. If the yes from the sensor only flips a variable inside your app, then anybody who can get the phone open can get your app open too, and your server cannot tell the difference. If the yes is the only route to a token your server signed, your server keeps control: it can revoke that token, expire it, or require a fresh sign-in after a password change. All of that belongs to app authentication rather than to the sensor, which is why the sensor is the small part of this job.

Decide the enrolment-change case before you ship. On iOS, storing the item with the constraint for the currently enrolled set means the item is invalidated when fingers are added or removed for Touch ID, or when the user re-enrols for Face ID. The looser constraint keeps the item readable after those changes. Android keystore keys have a comparable option, so check the exact flag in the keystore reference before you rely on it. The strict version costs your user one extra sign-in after they add a finger, and it stops a finger added to a stolen phone from opening your app.

What it costs to build in a React Native and Expo app

In an Expo project this is a small library and an afternoon, not a project. The LocalAuthentication module answers the four questions you need in order: hasHardwareAsync for whether a face or fingerprint scanner exists on the device, isEnrolledAsync for whether anything is saved to compare against, supportedAuthenticationTypesAsync for which kinds the device supports, and authenticateAsync for the check itself, which resolves to success true or to success false with an error.

Two configuration details catch people out. Apple requires a description of why the app uses Face ID, supplied either through the config plugin faceIDPermission property or as NSFaceIDUsageDescription in the Info.plist. And Face ID is not supported in Expo Go, so you need a development build before you can test it on iOS at all. Find that out now rather than an hour before a demo.

The library is the easy half. The work is the fallback path: a device with no sensor, a user who declines, a user who fails three times, a sensor locked out after repeated failures, and the first launch when there is no stored token yet. Each of those has to land somewhere sensible instead of on a dead prompt. That is ordinary app security basics rather than anything biometric, and it is where the day goes.

Expo, LocalAuthentication API reference

Build it, buy it, or skip it

Skip it when there is nothing behind the login worth a second lock. A read-only app with no personal data and no payments gains a nicer launch and one more way to fail. Skip it too when your users share devices, for the enrolment reason above, because the gate will not do what the person asking for it thinks it does.

Buy it, meaning do not write it yourself, when you already use a hosted authentication provider. Check whether its mobile SDK already stores the refresh token behind a device biometric gate, because if it does you are turning on a setting rather than designing a key store. We have not verified which providers do this, so read the SDK reference rather than the marketing page, and test that revoking a token from the dashboard actually closes the app session.

Build it when the login guards money, health information, private messages or anything an employer would call confidential, and the realistic alternative is people typing a password so often that they pick a short one. That is the case where biometrics raise security rather than only convenience. What each of those signed-in people is then allowed to do is a separate question: it is what the login unlocks, and it is worth settling before you write the gate.