local_auth: biometrics as a step-up, not a password store
local_auth: biometrics as a step-up, not a password store
local_auth is useful because it focuses on device support, biometric prompts, fallback credentials, and failure UX. The important engineering move is to place the package behind a clear boundary, so your Flutter UI depends on a stable capability rather than a vendor-shaped API.
What the library should own
- Keep package calls inside a named adapter or feature boundary.
- Make lifecycle, errors, and loading state part of a testable contract.
- Expose only the capability the app needs; hide implementation details from the whole tree.
A focused starting point
final auth = LocalAuthentication();
final supported = await auth.isDeviceSupported();
if (supported) {
final ok = await auth.authenticate(
localizedReason: 'Unlock your saved account',
options: const AuthenticationOptions(biometricOnly: false),
);
if (ok) unlock();
}
Production checklist
- Read the README and changelog for the exact version you pin.
- Add one test for lifecycle, failure, and app background/foreground behavior.
- Verify every platform your product supports, not only the developer machine.
- Record ownership, upgrade cadence, and rollback notes in the repository.
Common pitfall
Biometric success proves local user presence; still require server/session checks for sensitive actions.
Takeaway
A good open-source library does not replace architecture. It makes one difficult boundary clearer, observable, and easier to replace.