Why We Built a Local-First iPhone Authenticator Instead of Another Cloud-Synced 2FA App

LocalLensProject — Mon, 06 Apr 2026 03:24:00 +0000

Most authenticator apps force a flat security model.

Every token lives behind the same unlock flow.
Every account gets treated as if it has the same value.
And if you want stronger protection, the answer is often to make everything more cumbersome.

We thought that was the wrong tradeoff.

We’re a small team building LocalAuth, an open-source iPhone authenticator, and I’m the primary developer behind it. The project started as a small internal experiment, but it kept growing because we wanted to explore a different question:

What if a TOTP authenticator used multiple trust boundaries instead of one?

That led us to a 3-channel model:

Face ID / Secure Enclave for everyday accounts
a dedicated YubiKey channel for higher-value accounts
a generic FIDO hmac-secret channel for compatible security keys

From there, other design choices followed naturally:

local-first storage by default
nearby encrypted transfer for migration
no mandatory account layer for core use
an optional self-hostable Travel Vault for temporary off-device backup / restore
end-to-end encryption for Travel Vault, with encryption happening locally before upload

This post isn’t really about “shipping a new app.”
It’s about a design choice we rarely see in authenticator tools: not every account deserves the same protection model.

If you’ve worked on security tools, hardware-key flows, or local-first apps, I’d love to hear whether this approach feels practical or overengineered.

DEV Community: LocalLensProject

Why We Built a Local-First iPhone Authenticator Instead of Another Cloud-Synced 2FA App