Lets talk about changelogs (how I loathe 'bugfixes and performance improvements)

Look at SBCL's changelogs, I like those. I definitely would like that over "there are less bugs and it is faster".

One of the reasons larger apps post unhelpful changelogs like these is because they probably run a feature flag/experimentation system. It is a backend driven system that allows app developers to remotely switch on and off features and code changes. This is really useful when rolling out updated features, you can roll it out gradually, eg 1%, 5%, 10%, 100%. Roll out a new feature 1% and notice its crashing for a subset of those users? Roll back the flag so users see the old UI and fix the problem for next release. It’s better than updating a feature for all and having it crash for everyone (yes, even with testing sometimes bugs sneak through, especially when you have millions of users).

It also allows app developers to bucket users in groups and A/B test experiments on users to see what works best. It would not be uncommon for the larger players (Microsoft, Google, Facebook, Pinterest, Uber, Spotify, etc) to have 100s or 1000s of experiments running concurrently. It also decouples rolling out features from App Store releases.

Having said that, I also hate generic changelog messages and not defending the practice. If new features are to be launched with the build, write it in the changelog and add "(rolling out)" or "(coming soon)" next to it.

As a tech person, I don't care.

Most general users of apps on phones wouldn't give an absolute crap if you "fixed a buffer overrun in the X function", because that means nothing to them. If they read that you've made performance improvements, then great they can continue to play Candy Crush but not have it crash so often. They won't CARE that you "optimised the use of the strcopy function" or some crap like that.

Remember the app stores are targeted towards consumer users of phones, not tech people that live on Hacker News websites.

Every time I see “bugfixes and performance improvements”, I immediately assume that they’ve installed more tracking code.

Just like when I see “50% less sugar”, I immediately assume they replaced sugar with chemicals.

I think the key is describing the user-facing effects and impact. This means knowing your users (are they developers, IT or highly technical? Do they automatically or manually update quickly, or do they take time to evaluate before rolling out updates?). It's a way to convey continuing value to users and convince them it's worthwhile to keep paying, and get motivated to get the update.

I'd try to change what you wrote to something like:

"Fixed out-of-memory errors on some 32-bit systems"

"Improved startup time for configurations with lots of items"

This makes it easy to gauge if this update is important to get installed ASAP, such as fixing something they've experienced or are likely to experience.

Grouping "several UI fixes" or "performance improvements" is usually fine, but I tend to call out something like "fixed UI bug where a network error could result in changes not being saved with no warning" or an issue that a sizable chunk of users had reported.

Doing this well takes time, though, as you have to synthesize the internal ticket summaries, PRs and/or commit messages and reword almost everything. This is understandable for open source or free/indie apps, but for subscription/"enterprise" software it's definitely one of the differences between "great" and merely acceptable (or worse).