Local-First Apps: Why I Believe in Them for Certain Products
Local-first doesn't work for everything. A look back at Inner Gallery and the real use cases where keeping data on-device changes the game.
Local-first works very well for apps with personal data (photos, notes, journals). It gets complex as soon as real-time collaboration is involved. The Ink & Switch paper lays the right foundations, but implementation demands trade-offs.
You open Inner Gallery in airplane mode. Your photos appear instantly, you can organize them, encrypt them, create albums. Zero latency, zero server.
I built Inner Gallery on this principle after reading the Ink & Switch paper on local-first software. What if apps worked on the device first, with the cloud as an option?
Two years later, I can tell you one thing: local-first is fantastic... for the right apps.
What Local-First Actually Changes
Zero latency: No waiting, no spinners. You tap, it responds. Period.
Privacy by design: Your data never leaves your device unless you explicitly decide otherwise.
Resilience: Subway, elevator, spotty Wi-Fi? The app works perfectly.
Total control: Want to delete your data? Delete the app. Done.
Inner Gallery illustrates these benefits. Your photos are encrypted with your private key, stored locally. Apple can't see them, I can't see them, nobody can see them except you.
Local-first means taking back control of your data. But it comes at a cost in technical complexity and collaborative features.
The Perfect Apps for Local-First
After Inner Gallery and my experiments, I've identified the cases where local-first excels:
Personal vaults: password managers, photo vaults, private journals. Confidentiality trumps everything.
Creation tools: text editors, drawing apps, IDEs. You want instant response, working anywhere.
Quantified self apps: habit tracking, health metrics, personal data. It's YOUR body, it's YOUR data.
These apps share one thing in common: the user has absolute ownership of the data AND collaborative features are secondary.
Where Local-First Becomes a Nightmare
I tested local-first prototypes for other domains. The result: it's hell.
Social networks: How do you build a feed without a server? How do you moderate? How do you discover content?
Marketplaces: How do you sync inventory? How do you handle payments? How do you avoid double-selling?
Collaborative apps: How do you merge edits? How do you handle conflicts? How do you notify changes?
If your app thrives on real-time collaboration or content discovery, local-first will complicate your life for zero benefit.
The Technical Trade-offs You Must Accept
Complex synchronization: If you want multi-device sync, get ready for CRDTs (Conflict-free Replicated Data Types). Intellectually fascinating, a nightmare to debug.
Storage space: All data on the device takes up space. Inner Gallery stores photos locally, which can quickly add up to gigabytes.
Backup and restore: How does the user back up their data? iCloud? Manual export? That's on you to handle.
Performance: Searching through 10,000 local photos vs an optimized server-side search? You need to optimize differently.
For Inner Gallery, the MVP is 100% local. An end-to-end encrypted sync is planned down the road — data will never leave the device unencrypted.
Martin Kleppmann Was Right
Martin Kleppmann, the researcher behind CRDTs, predicted it: local-first requires rethinking the architecture from scratch. You can't just bolt local-first onto an existing app.
With Inner Gallery, I designed for local from day one. Core Data for storage, FileManager for photos, local symmetric encryption. No network component, no API, no server.
This architectural choice influences everything: UI (no loading states), UX (no "offline" messages), business model (no SaaS subscription possible).
My Decision Rules
Torn between local-first and traditional client-server? Here are the questions I ask myself:
- Is the data personal and sensitive? If yes, local-first makes sense.
- Does the app work solo or collaboratively? Solo = local-first viable, collab = server.
- Is zero latency critical? Creation, editing = yes. Social, e-commerce = no.
- Do you have the skills to handle the complexity? Local-first is not trivial.
For Inner Gallery: ultra-sensitive data, solo usage, critical latency, sufficient expertise. The choice was obvious.
For Coachy (my AI-powered coaching app), it was the opposite: less sensitive data, collaborative coaching, server-side AI required. Classic client-server architecture.
Further Reading
- Zero third-party dependencies: when it's worth it (and when it's not)
- Offline-first architecture: lessons learned
- Why I built Inner Gallery
Local-first is a powerful architectural paradigm. Like any paradigm, it has its optimal domains of application. Don't fall into the "local-first everywhere" trap: use it where it delivers real value.
Your users store sensitive data? Local-first. They want to collaborate and share? Client-server. It's that simple.