Local-first apps haven't become popular because users want shareable links, cross-device sync and maybe security.

For cross-device sync, you need a server. Either you use iCloud (limiting yourself to Apple platforms), host one (which encourages subscriptions and defeats the point of local-first) or ask users to self-host (which is difficult and error-prone).

Shareable links also need a server. You can't use iCloud for those, and if you're asking users to self-host, you now need to ensure their server is exposed publicly and has a domain. This adds yet another complication to an already complicated process, not to mention the security implications.

Security (where some users are restricted from seeing some of the data and performing some of the actions) requires much more "smarts" in the server, and makes local sync infinitely more complicated.

For local-first apps to be viable, we need a lot more primitives first. Apple provides some, but not nearly enough, and only for their own platforms. Nobody else even bothers.

▲

chris_money202 3 days ago | parent [-]

Creating a server devices can access on the same network is trivial the only issue you would run into is maybe what port to use and there are discovery processes for this.

	▲	miki123211 3 days ago \| parent [-]
		For that to work, you need a device which is online 24/7, always stays on the network, and does not have energy efficiency requirements, which justifiably limit background app activity. The only (consumer) devices that fulfill these requirements are routers and some smart gadgets, like fridges or smart speakers. None of them are easily programmable to a sufficient degree. This still doesn't solve the problem of sharing among users on different networks and accessing your data when you're not home. All these problems are solvable, but they'd require massive coordination among device vendors, and coordination is one of the hardest problems out there.