Even more amazing are the apps that require updates to run, yet they fail to display any meaningful 'you should update' message; instead, they abruptly crash with a catch () {throw new Exception("An error occurred");}.

That's completely un-amazing. If the ecosystem ensures 99.9% of your users are on the latest version, I wouldn't waste bandwidth on defensive programming for the 0.01%.

That is just what Continuous Delivery is though. Quicker release cycles keeps breakage short. It's a lot easier to manage "this edge case broke because of something we changed in the past day/week" compared to "something we changed in the past 3 months broke this edge case"

The lack of release notes is probably just not the effort, or even confusing for users and can deter them, or make them never read the release notes when they happen. I don't think most users know what semantic versioning is.

Like, if the only thing you did last week was refactor some module, add more unreachable code for a flagged feature, and update third party libraries, do the users need that info every week?

But not releasing all those small changes daily/weekly makes the releases more and more dangerous as they stack up.

A less charitable moniker for this approach is “eternal beta”.

There's a reason why we don't do Continuous Delivery in a high reliability embedded context: the costs of bugs can be very high if it turns out to brick the device or physically damage it. As the other poster put it, it's continuous beta, and I personally am not a fan.

I like my releases thoroughly tested.

You updated some third party libraries, and maybe there's some subtle thing that changed in them to cause a break. Maybe that refactor wasn't zero impact the way it was intended to be. As a user, sure I want to know about third party libs being updated. All of that is useful information for us to decide to take the update or not. Back in the good old days it was all information everybody gave as a matter of course. These days, especially on phones, it's opaque and you're forced to take it whether you want to or not.

edit: and the interface changing out from under us unexpectedly is incredibly off-putting. I hate that these days I never know when an application I use every day is going to decide to remove its menus or something similarly asinine inflicted on me because that's the latest trend in UX design.

So you fired your testing team, and replaced them with your users. Do the users get paid for that work?

The real release notes would probably be 'gather more analytics data, and show more ads, using 3rd-party advertising SDKs'

A couple of places I have worked had a ton of extra work when Apple would want detailed information about each release note item, and it just became easier to make the notes generic. Which I would guess is one of the reasons, with the other being tracking/ads.

> Almost none of them include meaningful release notes.

"Bug fixes and performance improvements"