Why haven't local-first apps become popular?

Economic / Business Incentives

• Many argue local-first isn’t primarily a technical problem but an economic one.
• SaaS/cloud offers recurring revenue, lock‑in, DRM-like control, upsell levers, and powerful data monetization; local-first undermines all of that.
• Investors and management often push products toward cloud hosting and subscriptions, away from on‑prem or self‑contained software.
• Even where local-first is technically feasible (e.g. single‑player games, productivity apps), companies often add always‑online DRM or launchers to preserve control.

User Demand and Behavior

• Most users prioritize convenience, collaboration, and cross‑device access over privacy or data ownership.
• Offline editing is a rare, niche need for many; offline read‑only is often seen as “good enough.”
• Many users no longer understand filesystems; cloud‑centric mental models dominate, making local-first harder to sell.
• People say they want privacy and ownership, but rarely pay or switch tools for that alone.

Technical & UX Challenges of Sync

• Building a local-first app implies building a distributed system: eventual consistency, retries, ordering, and failure modes.
• Conflict resolution is the hard part, especially in multi-user, collaborative scenarios (documents, calendars, inventory, reservations).
• Naive approaches like last‑write‑wins can silently discard work; “real” solutions require explicit merges, audit logs, or domain‑specific rules.
• UX is often worse: users must understand sync state, conflicts, and “offline drafts,” which is cognitively heavier than a simple cloud “source of truth.”

CRDTs, OT, and Git Analogies

• CRDTs and operational transforms are seen as powerful but complex, with difficult data modeling and migration stories.
• Critics note that “conflict‑free” only means convergence, not “matches user intent”; many real conflicts still require human decisions.
• Git is cited as proof asynchronous collaboration can work, but also as evidence that merge workflows are too complex for mainstream users.

Platform / Architecture Factors

• Web and mobile ecosystems default to server‑centric design; PWAs and browser storage are brittle and poorly communicated to users.
• Local-first works better in native environments (e.g. Apple’s Notes/Photos/Calendar with iCloud, some desktop apps) but those are often ignored in the “local-first” discourse.
• Self‑hosting and “personal servers” remain too complex for non‑experts despite tools like Tailscale, Syncthing, and similar.

Existing Niches and Counterexamples

• There are notable local‑first or offline‑capable apps (e.g. Obsidian‑style note tools, password managers, offline maps, Anki‑like study tools, some finance apps).
• These tend to succeed in niches where offline use, privacy, or long‑term data durability are obviously valuable, often backed by open‑source or hobbyist communities.

Critiques of the Article / Framing

• Some commenters say the piece is effectively content marketing for a SQLite sync extension tied to a proprietary cloud; it doesn’t address peer‑to‑peer or self‑hosted sync.
• Others argue the title misleads: plenty of local‑first or at least local‑plus‑sync apps already exist; what’s really being discussed is syncing strategies for web apps.