[mfDjB]

The reason these bigger apps just put "Bugfixes" and "Performance Improvements" in their changelog is because when you have many teams contributing to the software not only through actual code editing but also feature flagging what features go out on what release, rollback policies etc this becomes a nightmare to fill in. Doubly so when different users are receiving different experiences.

The article says at the end: "You see? Not that hard right?". It is that hard in bigger organisations.

[coldtea]

>The article says at the end: "You see? Not that hard right?". It is that hard in bigger organisations.

The size of the organisations is not important, as is the size of the team working on the particular feature/app.

Apple is huge, for example, but eg. Logic Pro has great changelogs.

We also see huge apps (with large teams) do better than than small apps (with much smaller teams). It's more about bothering/caring than difficulty.

[mackey]

Apple has a much more traditional engineering structure and traditional release cadence though. A lot of the "worst offenders" of these types of release notes are structured and work much differently. They release updates 1-2 times a week, sometimes release features weeks after the code has shipped to users, and sometimes in stretched out rollouts.

They say there if there is a will, there is a way, so in a sense I agree that these companies probably could do something about it if they really wanted to, but I also don't think it would be easy, and considering how few people actually look at release notes, I am not sure the investment is worth it.

[damnyou]

Logic Pro doesn't have server-side feature flags.

[coldtea]

Many apps don't have either, and they have shitty changelogs still...

[damnyou]

As far as I know all the big apps the OP is complaining about have server-side feature flags.

[joepie91_]

> when you have many teams contributing to the software not only through actual code editing but also feature flagging what features go out on what release, rollback policies etc this becomes a nightmare to fill in.

This is a terrifying sentence to me, because what it implies but doesn't say outright, is that there's not a single person in the organization who actually fully knows what is being released. If there were, then they should already have this information!

Honestly, if you don't have a release manager with a 30,000 foot view of the operation, you probably have bigger organizational problems than "it's hard to know what to fill in on the app store's release notes".

This is how retrospectives on supply chain attacks start, basically.

[JimDabell]

> This is a terrifying sentence to me, because what it implies but doesn't say outright, is that there's not a single person in the organization who actually fully knows what is being released. If there were, then they should already have this information!

It’s not the collection of the information that’s difficult, it’s delivering it to the user in an appropriate way when you use phased rollouts with feature flags.

The change log that the App Store presents to the user is static and identical for everybody. The changes that a user actually experiences are not. So you might have 0% of your users experiencing a certain feature when the release goes out, 10% a day later, 50% a day after that, and 100% at the end of the week. Or, if the metrics show a bad response, it might end up at maximum 10% seeing it, and then it dropping back down to 0% the next day.

Apple gives you a static text field to enter the change log information, with limited length. If you have ten different features to release, your users will all receive them at different times, and not all of them are guaranteed to make it out to everybody, how is a static text field supposed to deliver that information?

[Master_Odin]

"Begin rollout of feature <foo>" "We are rolling out <foo> in <timeframe> to ensure <x> about <y>, and rollback if <z>. You will notice you have <foo> when <bar>."

If you don't put anything about new features, don't be surprised when users don't use them (because why would they know) or complain what something "breaks" (or just changes on their workflow) because your changelog communicates nothing.

[JimDabell]

> "Begin rollout of feature <foo>" "We are rolling out <foo> in <timeframe> to ensure <x> about <y>, and rollback if <z>. You will notice you have <foo> when <bar>."

That’s a guaranteed way to get users complaining that they don’t have a new feature that you “promised” that they may never receive. It also isn’t appropriate for multivariate testing and just isn’t going to be understood by most users anyway.

There are way to do this in a decent way, but you have to do it within the application using your own logic. The change log provided by the platform is inadequate.

> If you don't put anything about new features, don't be surprised when users don't use them (because why would they know)

If you need to tell your users about new features in the App Store change log, then you’ve already failed because almost nobody sees it. Users know about new features because either a) it’s obvious when you use the application, or b) you tell them about the new features somewhere they will actually see it, at an appropriate time.

> or complain what something "breaks" (or just changes on their workflow) because your changelog communicates nothing.

A change log does not prevent this. You are attributing a lot of power to the platform change log that it simply does not have.

[SpicyLemonZest]

Many applications are big enough that no single person can hold the full details of what’s being released in their head. If a release contains a hundred changes from a dozen teams, there’s no way a VP or CTO sitting on top can understand them all in any depth, so “performance improvements + bug fixes” may well be the full contents of the 30,000 foot view.

That doesn’t mean it’s impossible to produce more detailed notes for a big application, but it’s a pretty involved process basically requiring a “release note manager”, not something that happens by default.

[toast0]

> there's not a single person in the organization who actually fully knows what is being released.

Sometimes there is, but as siblings point out, it's difficult or not cost effective to distill this information into an app store changelog blurb.

More often (in my opinion), it's the terrifying situation you describe. Nobody know what the heck is going on at an overall level. Which can work surprisingly well, but often means efficiency (network, memory, cpu, disk space) is very hard to come by.

[damnyou]

No. what it signals is that app releases are decoupled from feature releases. Of course people know when a new and important feature is being released, it's just completely independent of when the app store update goes out.

[0xbadcafebee]

Which is a good indication that the organization actually has no idea what the heck is going into the update.

[damnyou]

Assuming there are good rollout and incident review processes in place, this isn't much of a problem in practice.

[toast0]

If you're shipping a mobile app with client side code (so, nearly all of them), there is no good rollout process.

You can't ship a quick update with Apple, because review isn't quick. Users who upgraded soon after release will be stuck with something broken until the new version is available.

You can usually ship quickly with Google, but users are slow to upgrade, but may have caught your first one, and not get your second one for some time.

[damnyou]

I'm talking about feature flag based rollouts, which don't involve going through Apple or Google.

[toast0]

Hope you didn't mess up your flag system. Or your feature flagged feature doesn't corrupt your locally stored state.

[damnyou]

Yeah it happens sometimes. It sucks. It's where incident reviews come in, and feature flags are still better on balance for many apps.

[temac]

It is bugfixes or performance improvements about things that exist, though.

[hashkb]

Difficulty of task never excuses doing a lazy job. Especially if you hope people will pay you.

[fwip]

If it's worth doing, it's worth doing half-assed.