@manton I think the big thing there is that ++app version == ++feature is less and less of a thing every day.

For most major apps, features get added to apps but stay hidden behind feature flags until launch, so putting them in release notes would just be confusing to users.

@colin That’s true, but that’s a choice that these major apps are making. They could still align new releases with enabling new features.

You are absolutely right but as a developer and user I assure you that unfortunately no one reads those notes. Only us technicians.

Gosh, I could NOT agree more.

@manton I seem to recall they put out an edict something like five years ago saying the notes had to be better than that. Too busy policing Casey Liss's movie poster choices to enforce it, I guess.

@manton I don't think that's necessarily true, unless you're solo or a very small team.

Since most apps now involve multiple platforms and web services, all with different dev teams and business stakeholders (🤮), the App Store release is just one of 9000 dependencies, and it's a smoother rollout to stage everything first before turning it on.

I’m using Pixquare, a pixel editor, and there it’s the other way around. Every, yes every, week new features, really useful features, so many I can’t keep up. But still, the developer keeps up, as does their documentation. They are a machine, and it’s a single person. If Facebook did that, publish every feature and fix daily, users would run around with their hair on fire out of confusion.

@manton I read the notes before I install updates. I want a standardized definition of “bug fixes and improvements" (if it's fixing edge cases, performance, etc…) and to have those auto-install, and if there's user-facing difference I want to manually approve/install.