[saagarjha]

> Due to the policies and practices of app stores, we cannot always list security advisories within app release notes.

Yeah, right. Here's your three latest release notes for the iOS app:

  2.20.92 Aug 25, 2020
  Bug fixes.
  
  2.20.91 Aug 24, 2020
  Bug fixes.
  
  2.20.90 Aug 19, 2020
  Bug fixes.

Surely you can do better than that?

[amatecha]

IMO these walled-garden app stores that are supposed to be "so good for the users" should require quality release notes that describe the exact "performance improvements and bug fixes" that the respective apps apparently receive.

[2xlbuds]

There are quite a few reasons to have release notes like this:

1. Major apps often do phased rollouts of features in order to react to potential production issues, or to make certain features available to a limited subset of users or regions without having to do an emergency binary release if things go wrong.

2. The new build contains an A/B experiment, and you don't want to tell users that feature X was revamped because the experiment might not even go anywhere and only a small number of users will see it, anyways.

3. Your app is stable enough to have a regular release cadence e.g. monthly or biweekly, and you actually are just shipping whatever bugfixes made it into master since the last release with the major feature changes hidden behind feature flags until they are ready for 1. or 2.

4. The vast, vast, majority of users never read the update notes on the app store. They have automatic updates enabled, and your app updates at 3AM when their phone is plugged in on wifi and they are fast asleep.

5. Building on 4, if you actually want to advertise new features to users, it is better to build a native experience into the app either building a UI highlighting what has changed in the new version, or just popping up a dialog to show the patch notes (can be coupled with 1. and 2. to only show the dialog to users who have gotten the new feature enabled in the phased rollout or experiment). Discord is an example of an app that does this well.

6. Also building on 4., the changes are so minor that they are not worth paying a translation service to translate your patch notes if you are offering your app in multiple languages.

[amatecha]

Sure, I'm aware of those reasons (and can think of many more). As a user/customer, I don't care about any of those details. I still want to know what's changing when I click "Update".

If users have automatic/background updates, sure, they apparently don't care about release notes. For everyone else, the release notes are really the only way to know what changes are going to happen upon clicking "Update". Having those notes be [effectively] blank is a substantial disservice to the user.

It's depressingly frequent that an app I used to enjoy takes a major dive in user experience. For a contrived example, I don't like finding out I am now suddenly blocked from using my messaging app because they force me to use a new cloud-based account system I can't opt out of, and none of this was mentioned before I clicked Update. Or another favorite: an update that does nothing more than introduce in-app advertisements.

[1vuio0pswjnm7]

I would prefer an "app store" that required apps to be open source. This would allow everyone to see exactly what is being done by the developers. Release notes alone are not of much use for the public in the case of closed source apps because the public cannot take a closer look. Is anyone really going to look at a release note that says "Bug fixes" and make a qualitative decision on the app? With lots of such notes we could conclude the developers are busy fixing things (good) however we could also conclude the app when released contained many latent bugs (bad). But we need to see the source changes to truly understand what are the circumstances. Perhaps such vague release notes are not actually published for the benefit of users but for some other reason(s).

[ffggvv]

apple actually banned update descriptions like that a few years ago. when they announced it they started enforcing it but i goes over time they’ve gotten lax or just give big companies exceptions

[tinus_hn]

Apple is going to have a hard time enforcing this when 90% of their own updates are described as ‘bug fixes and performance improvements’

[amatecha]

I've collected screenshots of app updates with that text as their release notes so I can one day start a "bug fixes and performance improvements" tumblr or blog or the like. It's just such a joke to me. Kinda like software installers that put the GNU Public License as their license agreement you have to agree to before installing, haha

[reaperducer]

IMO these walled-garden app stores that are supposed to be "so good for the users" should require quality release notes that describe the exact "performance improvements and bug fixes" that the respective apps apparently receive.

What is it that makes you think this is caused by "walled gardens?" Do you have a link to a policy that requires this, or is it your own biases showing through?

[amatecha]

I think you may have misunderstood my comment... I'm saying that if the walled garden app stores are supposed to be good for users (especially if this is one of their marketing bullet points), one might reasonably expect that "high-detail release notes" ought to be one of the requirements for app developers, imposed by the owner of the app store (Apple, Google, etc.) .. This way users get a good understanding of what changes will happen when they download an update of a given app.

[Shared404]

They are stating that if the walled garden is supposed to benefit users by curating, they should be curating.

In this case, they should be curating patch notes.

[dudus]

I'm on the other end of the spectrum. Since the updates are constant, often required and automatic it makes little sense to provide these in the store itself. The user doesn't really have a choice of not updating most of the time. It's not a decision they should make I'd rather see release notes outside the stores, for more technically inclined users only.

[iso8859-1]

Users would be scared by reading technically accurate release notes. So for apps as ubiquitous as WhatsApp, it makes sense to have two kinds of release notes, one for techies, and one for commoners, who only want to know whether features were added or not.

[amatecha]

Disagree 100%. I don't expect technical detail, I expect product change detail. Have you ever looked at Slack's release notes? Easily digestible and they don't need to go into deep technical detail to say that a given feature behaves slightly differently now. I expect a bit more than the totally-meaningless "bug fixes". Even something as simple as "icon update, old messages now stored in Archive tab". I just don't want crazy surprises like a total UI overhaul where tons of stuff I'm used to is just suddenly gone.

[ColanR]

Having dealt with my share of technically-unsavvy users, I can confirm that half the job is managing their feelings. The other half is working around them to keep things safe and functional in spite of them.

[Sosh101]

That's so patronising.

[kinkrtyavimoodh]

It's way less patronizing than the policies of the App Store.

[iso8859-1]

If it was sufficiently patronizing, users would be offended and WhatsApp would not be popular. Therefore it cannot be as patronizing as you claim.

[ssss11]

That sounds logical in theory but in practice users may use a tool and still loathe it. Their choice to use WhatsApp is partially dependent on their contacts’ choice to use it.

[bitten]

so if a tree falls in the woods and nobody is around to hear it.. it didn't make a sound? ;)

[kbenson]

I imagine for some instances, it's because a security fix might have gone in, but they don't want to clue attackers on other platforms. For example, if the fix is submitted for the Android and iOS apps to their respective marketplaces for review at the same time, and one is authorized and goes live first, then you've released information that's useful to someone looking to exploit the other (they now know there's something to look for in the differences of how they operate).

That is, unless both stores allow you to get the version authorized but hold it for release until you want. I know the Roku store did that years ago, so I imagine it's probably a feature that's present in those stores, but I don't know for sure.

[2xlbuds]

That's another great reason to be vague, because even if you were able to launch your updates at the same time on all platforms, at least on mobile the adoption rate can be relatively slow - on mobile I've measured that it takes about a week to get 80% of users to update and 2 weeks for 90%, which could leave a sizable vulnerable population.

[saagarjha]

Both the Google Play Store and Apple's App Store have this feature, I believe.

[eysquared]

Well there is at least one reason that release notes are bad: any mention of any new feature or specific fix seems to trigger more scrutiny from Apple reviewers.

The more information you provide, the more likely it is that your app will be held up in review or you will get additional questions from reviewers delaying your release.

I generally still try to err on the side of including information in my release notes, but I have been bitten by this enough times that I completely understand this practice and sympathize with other app developers.

[dilippkumar]

Well, there isn't any listed security fixes for iOS:

https://www.whatsapp.com/security/advisories/2020/

Edit: Discard this comment, read saagarjha's reply below.

[saagarjha]

Most of the ones listed there seem to apply?

[dilippkumar]

You're right. I didn't read these as carefully as I should have.

[saagarjha]

No worries, happens to the best of us :)