[klabb3]

> How about we don't build an auto-updater?

Sure. I’d rather have it be provided by the platform. It’s a lot of work to maintain for 5 OSs (3 desktop, 2 mobile).

> we should try our best to release complete software to users that will work as close to forever as possible

This isn’t feasible. Last I tried to support old systems on my app, the vendor (Apple) had stopped supporting and didn’t even provide free VMs. Windows 10 is scheduled for non-support this year (afaik). On Linux glibc or gtk will mess with any GUI app after a few years. If Microsoft, Google and Apple can’t, why the hell should I as a solo app developer? Plus, I have 5 platforms to worry about, they only have their own.

> Touching files on a user's system should be treated as a rare special occurrence.

Huh? That’s why I built an app and not a website in the first place. My app is networked both p2p and to api and does file transfers. And I’m supposed to not touch files?

> If a server is involved with the app, build a stable interface and think long and hard about every change.

Believe me, I do. These changes are as scary as database migrations. But like those, you can't avoid them forever. And for those cases, you need at the very least to let the user know what’s happening. That’s half of the update infrastructure.

Big picture, I can agree with the sentiment that ship fast culture has gone too far with apps and also we rely on cloud way too much. That’s what the local first movement is about.

At the same time, I disagree with the generalization seemingly based on a narrow stereotype of an app. For most non-tech users, non-disruptive background updates are ideal. This is what iOS does overnight when charging and on WiFi.

I have nothing against disabling auto updates for those who like to update their own software, but as a default it would lead to massive amounts of stale non-working software.

[RadiozRadioz]

> file transfers. And I’m supposed to not touch files?

I'm pretty sure you know what I meant, it's obvious from context. System program files. The files that are managed by your user's package manager (and by extension their IT department)

[klabb3]

There isn’t a package manager in many cases: windows store requires a MS account. macOS app store nerfs apps by sandbox restrictions. Linux has so many flavors of package managers it’s death by 1000 paper cuts. None of the major bundlers like flutter, electron and tauri support all these package managers and/or app stores. Let alone running the infrastructure for it.

Which leaves you with self-updaters. I definitely agree ideally it shouldn’t be the applications job to update itself. But we don’t live in that world atm. At the very least you need to check for updates and EOL circuit breakers for apps that aren’t forever- local only apps. Which is not a niche use-case even if local-first infra was mature and widely adopted, which it very much isn’t.

Anyway, my app works without internet, pulls no business logic at runtime (live updates) and it uses e2ee for privacy. That’s way more than the average ad-funded bait-and-switch ware that plague the majority of commercial software today. I wish I didn’t have to worry about updates, but the path to less worries and healthy ecosystem is not to build bug-free forever-software on top of a constantly moving substrate provided largely by corporations with multiple orders of magnitude more funding than the average software development company.

[pl4nty]

> windows store requires a MS account

they avoid mentioning it, but the Microsoft managed package format (MSIX) works just fine without the Microsoft Store. create an App Installer manifest, stick it on a website, and get semver-d differential updates across multiple architectures for free: https://learn.microsoft.com/en-us/windows/msix/app-installer...

msft have woefully underinvested in the ecosystem and docs though. I wish they'd fund me or others to contribute on the OSS side - electron could be far simpler and more secure with batteries-included MSIX

[klabb3]

That's interesting and unexpected. How does the update check, notification & install process work?

EDIT: I think your link answered some of these questions. I’m on .msi myself so can’t benefit from it yet anyway.. basically these things need to be managed by the app bundlers like electron & tauri otherwise we’re asking for trouble. I think..

[account42]

> This isn’t feasible. Last I tried to support old systems on my app, the vendor (Apple) had stopped supporting and didn’t even provide free VMs.

Why do you need "free VMs" as a professional software company. A couple of legacy machines is pocket change comparet to the salary of even a signle developer.

> Windows 10 is scheduled for non-support this year (afaik).

So? People are still releasing new software for XP. It's not that hard.

> On Linux glibc or gtk will mess with any GUI app after a few years.

glibc provides extreme long-term backwards compatibility so isn't a problem as long as you build against the oldest version you want to support.

gtk is a problem but also doesn't change as often as you are implying - we are only at version 4 now. And depending on what software you are building you can also avoid it.

> If Microsoft, Google and Apple can’t, why the hell should I as a solo app developer? Plus, I have 5 platforms to worry about, they only have their own.

So that your users have a reason to choose you over Microsoft, Google and Apple.