These need not be the only two options. App developers could charge money for updates made i.e. new versions while the old versions keep working as advertised.

Instead of "cloud storage" which might incur ongoing charges, apps can very well hook onto my GDrive/OneDrive to persist data. Also, games have done this "free updates to this app I paid" for years now.

Yes, "pay for a major new version" was the industry model for many years. Office, Photoshop, etc. In the end you're sort of forced to upgrade by file compatibility every two or three years, so it's a subscription with a slightly uneven payment schedule.

There are still some apps that do this, Things is a good example. But that creates all kinds of other challenges when a big part of the product is a service (like ours) if you want to support all versions of the client in perpetuity.

Charge for update. If I like new features, I’ll pay. If not, I’ll stick to old version.

Why would maker take away old version from me if I don’t like the new version?

It's a service, so there's a substantial maintenance cost to maintaining multiple versions. Curious if you also feel this way about Figma or Notion? Or for that matter, auto-updating software like Chrome or iOS?

Why not use iCloud and structure schema to let old versions survive? Solves both issues.

I don’t know what Figma or Notion is. But I dropped beloved Tower git client when they went subscription-only. I still sometimes use their last purchasable version though.

Regarding iOS, It’s possible to refuse updates. I also used iPhone 6 for a looong time and went several years without upgrading OS. I also still use old iPad 4 that receives no updates for years. What can I say… it was a good stable ride!

I don’t care about novelty for the sake of novelty. Once I find a tool I like, I’ll use it as long as possible.

And I’m happy to pay through the nose for quality tools. Be it kitchen utensils or gardening tools or electronics.

You might want to read the original post--a core feature you're paying for is local-first sync, which is explicitly designed to solve a lot of the problems with iCloud.

I do want to see a world where there is a generic syncing service (maybe AWS can run one, but open standards / open source) similar to Dropbox or iCloud. I can pay one lump sum for all my storage and all my apps will connect through it. But so far no such thing exists outside of the crude file-based syncing of Dropbox, and that's not suitable for building realtime apps on top of.

Okay, then maybe that local-first sync can easily support multiple schemes and let old versions run without overhead to devs?

Personally I'm fed up with syncing both as a user and as a developer.

As a developer, I don't want to deal with infrastructure for an app. It's a massive headache to have 24/7/365 responsive system. I want to make apps, not be on-call sysadmin.

As a user, I don't want to worry who is going to sell my data after going bankrupt. And I'd prefer small dev shops don't waste their time on keeping network infrastructure up and running with security patches.

> local-first sync can easily support multiple schemes and let old versions run without overhead to devs

I'd love that. Ink & Switch has done extensive research on how to enable this with p2p technology etc. Our industry isn't there yet... but lots of good folks are working on it. The Muse sync setup is a step in that direction.

> As a developer, I don't want to deal with infrastructure for an app. It's a massive headache to have 24/7/365 responsive system. I want to make apps, not be on-call sysadmin.

Oh yes. I spent many years carrying a pager for Heroku's infrastructure. Part of the appeal of local-first is the sync infrastructure is necessary to transmit data between devices, not for every single keystroke or gesture the user makes.

The model can and has been done successfully, see jet brains for a great example.