14 ms·

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

241 points by jandeboevrie 6y ago

jrootabega 6y ago
In an "app store" context, the apps don't serve you; you just generate content/engagement for them. The apps you're looking at don't WANT you to be informed because you might choose not to use them. These notes are just a formality standing in for forced automatic updates. Spotify on Google Play is particularly insulting. They basically tell/shame you that you should just always update without caring about the changes.
- coldtea 6y ago
  >In an "app store" context, the apps don't serve you; you just generate content/engagement for them. This is a non-sequitur. There are all kinds of apps in an "app store" context, and the apps I use serve me very well, thank you. I also don't generate any "content/engagement" for any of them. Whether apps have good changelogs or not is also not a factor of whether the apps are in an app store or not. You maybe meant to say "social apps" as opposed to "app store" apps.
  - jrootabega 6y ago
    I guess I'm focusing on the ones at the top of the food chain, and the what I think is the predominant relationship in app stores, not necessarily the social ones. Eg the Microsoft ones in the article
henkdevries 6y ago
If an app is good enough, developers and managers and "agile coaches" and such don't stop, they start doing busywork. It looks like they're working and progressing, but all they do is scare users away with by removing features, breaking workflows and more horrible stuff. You're just making money for the shareholders, nothing more. They don't care about users...
- dvfjsdhgfv 6y ago
  In the case of many popular apps, it's a bit more than that: they're actively fighting what they perceive as bad actors, that is people trying to use their app not as intended, using their protocol outside of the official app and so on. In this case they have nothing to gain by describing the changes in more detail in the changelog.
johannes1234321 6y ago
With many apps an issue for changelog writers is that often behavior is tied to feature flags, which can be remotely enabled. Thus a new feature is rolled out in the app but only visible to some testers. Only after a while it's enabled for all users. Thus app release is independent from availability of a feature. That said "Bugfixes and performance improvements" is as useless as it gets ...
- vbezhenar 6y ago
  I wonder how those features pass Apple review? It's easy to disable those flags to get review passed and enable them later.
  - robotnixon 6y ago
    I'm pretty sure that's what Fortnite did right before they got kicked out of the App Store. Before my company implemented IAP in a few of our apps we did the same thing, but decided the risk was too great. Getting rejected is one thing, but getting your account terminated is obviously a much bigger deal.
  - JimDabell 6y ago
    You provide Apple with login details when you submit your application. Just enable all the features in advance for Apple’s test account.
  - mackey 6y ago
    It depends on the feature. For things that involve material changes to your app or a feature that you don't want Apple to be surprised about, usually you will include user credentials in your submission that have that feature enabled and give them a heads up. If's a smallish feature, you don't usually sweat app review. It's obviously not a perfect system.
  - saagarjha 6y ago
    You are supposed to list all the feature flags and explain how to enable them in your review notes.
mfDjB 6y ago
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.
- temac 6y ago
  It is bugfixes or performance improvements about things that exist, though.
- coldtea 6y ago
  >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 6y ago
    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 6y ago
    Logic Pro doesn't have server-side feature flags.
CJefferson 6y ago
The problem is often the "bugfixes and performance improvements" are a list of 60 things, and for almost all users "there are less crashes and it is faster" is all they would want to know. How many users want to read (OK, possibly people here) "On some versions of glibc, the 32-bit specialisation of memcpy which used SSE2 instructions had a bug when the memory being copied crossed the 2GB boundary, so in that case we now use our own memcpy" Or "Changed some internal lists to be only be sorted when they need to be rather than eagerly sorted whenever elements are added, which speeds up start-up time".
- jandeboevrie 6y ago
  Hehe I'd be happy to read such a changelog
  - sltkr 6y ago
    I doubt you would. A large app each would have hundreds of changes like this. It would get pretty boring after the first dozen or so.
- degenerate 6y ago
  A lot of people here would like this level of detail, actually. But general apps are intended for the general population, which is why big orgs go for the minimum watered down version. It's more work and overhead if they confuse their users.
- christophilus 6y ago
  I prefer the detail. You could always make the first line: “bug fixes and performance improvements” with details following. Then people who don’t care can ignore the details, but people who do care can get an understanding of what the change is about. Deep understanding of a change is really helpful when looking through history or trying to make sense of why this particular line was changed, etc.
  - bauerd 6y ago
    This is about app store changelogs, not commit messages
alexcroox 6y ago
I automate the app deployments for our team and “bugfixes and performance improvements” is the changelog because it’s totally automated on release. Yes the automation could grab something from the commit logs but I’m not confident I’d want to expose some of our commit messages. Also recent versions of iOS have further hidden away the update ui making it very hard to find for most users, so why bother taking the time to add them manually when 99% of your user base will never see them?
- Kudos 6y ago
  You can maintain a file with the current/next changelog in your vcs and pull from that. Works with automation, but is still curated.
- kingosticks 6y ago
  I think I'd argue it's not "totally automated" unless skipping the changelog generation step was the intention. In which case no need to justify that with any reasons, that's your (valid) choice to omit some documentation. We used to maintain our "customer-facing" changelog as we merged the associated code but that did create work when trying to release and finding some people had forgotten to provide an entry, which ultimately reduced release frequency. So now we don't include a changelog in the release itself, we create it after the fact and it's more of a "living" document hosted online (having to create another new release just because of dumb mistake in your latest changelog is really annoying). For those that are really interested, they can check the commit logs. For those less interested, they can wait for the online changelog to be written. It's likely they'll only have to wait a few minutes. Obviously the former is easy for open-source projects. I'm not convinced our new way is better yet but I'm willing to wait and see if the release frequency improves.
- saagarjha 6y ago
  > Also recent versions of iOS have further hidden away the update ui making it very hard to find for most users Thanks for your contribution to society, Apple Arcade.
twright 6y ago
One time I wrote simply “bug fixes” for an app update and it got rejected because the description was too short. I changed it to something more in the lines of “bug fixes and improvements” and it got accepted. I generally like writing changelogs for users but I also wonder how many people have automatic updates on and never read them.
jka 6y ago
As with many others here no doubt, I spent a lot of time in 2020 viewing diffs between library versions, reading changelogs, and tracking upstream bugs/features. Although I'll try to resist going on too much of a pro-FOSS rant, the change audit process is much easier for open source projects since you can read not just the changelog entries, but also the corresponding code to verify the claims. That helps with various things including developer trust - it helps you determine whether a project and authors use test coverage to reproduce bugs and prove their fixes, whether performance improvements are measurable, whether there are risky side-effects to look out for, and so on. Increasingly I think that these kinds of 'software due diligence' should become part of recommended software engineering workflows, and that makes me wonder whether some of the repetitive aspects can be automated. A genuinely user-focused, trustworthy app ecosystem would, I think, allow some of these 'change audit' processes to be visible to users so that they can make informed upgrade decisions, and to create a marketplace incentive for upgrades to be reliable.
deleted 6y ago
[deleted]
cesarb 6y ago
The worst of these is the "Google" app. For over a year, every single new version has the exact same four-entry changelog, which translating from Portuguese is something like: "enhanced search page appearance; new doodles designed for app experience; off-line voice actions, available only in the USA; web pages opened directly within the app". I have the slight suspicion that most of the almost weekly updates to the "Google" app do not have these four changes... for that app, "bugfixes and performance improvements" would actually be a better (more correct) changelog.
- WesolyKubeczek 6y ago
  Let me guess: the most recent changelog is getting picked up for every new version.
altitudinous 6y ago
I used to love posting detail about what I change in my apps. But now the text isn't really surfaced - folk have automatic updates turned on, and the text is deep in the app store now. My changes are mostly technical when I use the "bug fixes and performance improvements" text, but I tend to write more for the app store reviewers to let them know what is going on. I know they read it. In the end my audience of users are very non technical. I am authentic to them, that is the image that I sell my apps with, and I am good at it. So they just don't care that I've updated library X, or improved error handling somewhere, or I support Apples latest devices now. They do have faith that I am doing the right thing, and they write to me as if they know me, and I like that.
Santosh83 6y ago
These are changelogs for end users, not fellow developers. In fact I expect that even these "one line notices" will be dispensed with in future as the concept that any software or device requires an always-on connection to the Internet becomes fully normalised. Apps/devices will simply update and that's that. You won't be given any sort of option or toggle. Does anyone seriously ask the govt NOT to maintain a road or bridge? Such will be the case with software too. Individual freedoms and privacy have no future in the direction technology and society are going.
- saagarjha 6y ago
  You can be annoyed when someone comes by to bulldoze your house to build a hyperspace bypass, though.
magoon 6y ago
What it takes to get through app review
kevin_b_er 6y ago
Because you aren't meant to know what the changes are, just consume.
CM30 6y ago
Yeah, it is nice to know what the actual changes are, rather than a vague 'fixes were made' statement. Nintendo's update logs for games have to be some of the most hilariously vague in that regard, with many of the updates being just: > Several issues have been fixed to improve gameplay experience. But at the same time I guess I can see why companies and project creators don't go into more detail. Maybe the actual bugs fixed were so weirdly technical that most users wouldn't understand them at all, or care (if the user hovers over this button for 1/300th for a second, there's a 0.0001% chance their next message might not save properly). Maybe they (perhaps sadly) don't remember what exact things they fixed, since they fixed so many bugs. Either way some more detail would be nice for those that do care about this stuff.
- rubyist5eva 6y ago
  > Nintendo's update logs for games have to be some of the most hilariously vague in that regard On the flip-side, the changelogs for Super Smash Bros Ultimate and Splatoon 2 are some of the best I've ever seen.
blargmaster42_8 6y ago
Translateing : #$(ticketId) Resolved by $(implementation details) into something the end user understands IS HARD!
Rockslide 6y ago
> If that is all you're going to put there, then just leave it blank. Well, I would love to. Unfortunately neither Play Store nor App Store allow you to do that... so "bug fixes and performance improvements" it is, 99% of the time.
TrianguloY 6y ago
I also have automatic updates off and I really like checking changelogs to know what new things I can play with. And I don't mind reading 'bugfixes and performance improvements' ... but only if that's really what the new version is about. I like changelogs, but even for me a 'we fixed an issue where if you enter a 1025 characters text into the title textbox and press back twice while rotating the phone the app closes' is probably too much, but if you added a new option to increase the text size please say it, I don't want to check all the settings screens each time each app updates, and more often than not someone tells you 'hey, aren't you using this option?' No, no I wasn't, because no one told me. Are you a big company and you have automated updates? Why not have an automated checklist of changes too? I'm sure you have a 'roadmap list', so use it.
ChrisMarshallNY 6y ago
My changelogs are pretty complete. One reason might be that they are not automatically generated. I hand-edit each entry. Sometimes, I copy and paste the changelog entry into the last commit of the release (but I make sure to have a short, succinct initial sentence, as that is what shows up in Git browser history). The changelog may end up being a lot more "generalized" than the commit comments, though, as it's meant to be read by users. I appreciate the kinds of changelogs that you usually get with developer tools, where they are like encyclopedias.
deleted 6y ago
[deleted]
nudgeee 6y ago
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.
recrudesce 6y ago
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.
xyzelement 6y ago
I just looked at WhatsApp (one of his examples) and it has a detailed "what's new" in both the Apple and Android app stores that's listing three high level features. Sounds like the screen shot he took in September really was a bugfixes and performance release. So it sounds like these apps (at least, WhatsApp) follow a wise policy - tell the users what has changed that matters and don't drown them in irrelevant information. I had the same policy for my teams - tell users 4-5 new features/changes to workflow they are going to see and for g-d's sakes, do not drown that out by listing 400 irrelevant infrastructural changes we happen to be pushing out.
joshspankit 6y ago
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.
thomaspaulmann 6y ago
For early-stage startups, writing changelogs is also a great way to close the feedback loop with their user-base. We write detailed release notes at Raycast [1] to highlight feedback that we addressed. This way our users see that we care about their feedback and feature requests. [1] https://raycast.com/changelog https://raycast.com/changelog
awinter-py 6y ago
> probleemoplossingen en prestatieverbeteringen love 'bugfixes and performance improvements' in dutch
enra 6y ago
As a startup we write fairly detailed changelogs weekly [1]. For us it has been a major way to communicate all the new features and fixes as they come available to users. It’s also a good way for the team to celebrate their accomplishments. I was surprised to learn it also had helped with investors and generally marketing. Usually the person who was a major contributor to the highlighted feature of the week writes the changelog and then we look through our PRs to add anything that could be interesting. We don’t include things like “migrated x” “upgraded library x” if there is no visible benefit for there. Wrote about the lessons here: https://link.medium.com/9YuBV3dUIcb https://link.medium.com/9YuBV3dUIcb 1: https://linear.app/changelog https://linear.app/changelog
ulisesrmzroche 6y ago
Maybe like a couple bullet points, nothing too technical, but it’s a good spot to talk to your customers and make them happy. It does depend on the product though. I can see a developer tool maybe even just going so far as to putting out their internal change log, but for other customer segments, it’s best to keep it short and (hopefully) funny
phreack 6y ago
Worst offenders aren't even those. Some go as far as an 'Information not provided by developer', and the worst of them all - Netflix's 'You just worry about what to watch next.'. Irritates me to no end, I now only update manually and if there's no apparent benefit I just don't. Saved me from seeing some apps' changing icons into something awful, or hostile UX redesigns. It was a shame when Discord, who used to have some of the very best changelogs, turned into this practice.
deleted 6y ago
[deleted]
olivierlacan 6y ago
This is precisely why I started https://keepachangelog.com/ https://keepachangelog.com/ many years ago. Release convenience shouldn't come at the cost of properly communicating about notable changes for software users (whether developers themselves, or software consumers). Instinctively, developers reach for automation to solve this problem but this is an editorial problem for most software. Code changes very rarely map to notable changes for your intended audience. Even with rigid system like conventional commits, you can't entirely automate proper human-focused changelogs and release notes. You're going to have to clean things up and editorialize if you really care for your software users to understand what notable changes are included in a given version release. If you can't think of any, maybe you're releasing too often. If it's impossible to tell things apart because there are so many changes as another commenter pointed out, I think you have a way bigger problem.
rpearl 6y ago
when we build a new feature, it's gated by a flag controlled by the server. The app version with the feature is distributed well in advance of the intended rollout. So, we can't even put the new feature in the change log for the update that includes the feature, and the rollout won't be associated with an app update. All we can really put in the change log is bug fixes, and the circumstances that result in a bug can often be obscure and hard to describe in user-facing terms, so it gets summarized: "bug fixes and performance improvements". And for the play store and the app store, we have to put _something_.
p0nce 6y ago
The D compiler have had a great changelog since years and it has made a difference to popularize what went into an update. Each major change comes with examples, and it's great content. https://dlang.org/changelog/2.095.0.html https://dlang.org/changelog/2.095.0.html
baby 6y ago
That was not really interesting, so I'll start a related thread: - why is performance often favored instead of improving, refactoring, documenting, simplifying, etc. And how can we change that? - why are bug fixes so hard to track? Often developers fix something without marking it as a bug fix. And how can we change that?
rodone 6y ago
Bugfix: closed open single quote in title.
WalterBright 6y ago
We list all the changes: https://dlang.org/changelog/2.095.0.html https://dlang.org/changelog/2.095.0.html
- mottosso 6y ago
  Yes, this!
mottosso 6y ago
This topic and responses to it warms my heart. :) I've made it a habit for my current project to turn changelogs into blog-like material for the end-user. The kind of changelog I would like to see from other software, especially the kind I care about. For example: https://learn.ragdolldynamics.com/releases/2020.12.01/ https://learn.ragdolldynamics.com/releases/2020.12.01/
brokencode 6y ago
How much value does the average user get out of better patch notes? None, since they don’t even read the patch notes. So is that worth the time for each issue to write and edit a user-facing piece of documentation? Every little task like this is a waste of time and mental energy that slows down useful work. In my opinion, this is just not worth the effort.
- bartread 6y ago
  I too basically disagree with the author (for reasons I'll go into below), but I think it's worth unpacking a little further that high quality release notes can form an important part of your communication strategy with your users. Note: high quality. Many years ago I worked for a tools company where, for our less popular tools, user count would be in the thousands to tens of thousands, and for the more popular tools, it would be in the hundreds of thousands. Every single time we put out a release you could guarantee that a handful of people would ask for release notes even though we'd always publish them. Clearly people wanted them. Now I work for a company where our platform caters to two very distinct groups of users - one group internal, the other external. Particularly for the internal users release notes are hugely important in order to avoid disrupting their work and deliverables to customers. In both companies we've often had an "additional bug-fixes and performance improvements" item in the list. Why? Because people only have so much attention to go around: they're busy and, particularly in my current role and with our internal users, it's critical that we draw that limited supply of attention toward the most important changes. That's much more valuable than sending out an exhaustive document of every single change every time we do a release. We've found that if we supply exhaustive notes, fewer people tend to read them, and we get complaints that they're too long. As you've already suggested it comes down to ensuring that the release notes you provide are actually valuable to users. Together with other documentation and training materials, release notes can provide a useful jumping off point for learning how to work with changes and improvements to our software. (Not everybody reads them, of course, but having them does at least mean that when they inevitably ask for help/information, we can point them at the release notes as a starting point.)
einpoklum 6y ago
It is much more likely to see decent Changelogs on Free Software. (For many reasons, but including: "We added a new backdoor to satisfy government mass-surveillance program requirements.)
dasil003 6y ago
Contrarian viewpoint: I'm very passionate about this idea for open source software, especially things like ruby gems or npm packages that I might use as a dependency, but for some reason I can't muster the indignation to care about this for apps. Maybe it's because I care primarily that the app works and the latest version is stable. I'm generally not going in and considering upgrades to apps strategically, and even if I did I have no ability to see the previous changelogs let alone install those versions. If for some reason I want to avoid an upgrade now I'm living on borrowed time and need to start thinking about a replacement or carefully curate my backups so as not to lose access. Sure in a perfect world it would be nice to have perfect changelogs, but it's so far down the list of things I want out my apps that I place zero value on it.
richardwhiuk 6y ago
Those changelogs are likely wrong anyway. If you miss an update, you'll miss the intervening changelog. There's no ability to provide multiple changelog entries in the app store.
XCSme 6y ago
When I make performance changes I like testing the actual gains on the live server and add them to the changelog, something like: "Improved profile page loading speed by 25%". For reference: https://docs.usertrack.net/changelog#usertrack-3-3-1-11-december-2020 https://docs.usertrack.net/changelog#usertrack-3-3-1-11-dece...
lxe 6y ago
Thank you for choosing [app] - the best [thing] for [thing that it does]! We are committed to continuously improving the experience of bringing you the best of [thing that app does]. We update the app regularly so we can make it better for you. Get the latest version for all available [app] features. Love [app]? Rate us 5 stars!
- grishka 6y ago
  Meanwhile nothing at all changes with updates but there are hundreds of server-side settings that change all the time because metrics gotta grow. Eternally. Into infinity. And don't you dare get used to the UI.
sirsuki 6y ago
The FOSS community still campaigns the idea of Open Sourced software on desktops. Why then is the same not as popular in other platforms like iOS or PWAs? I truly wish I could visit github.com/[my-iOS-ap]/project and contribute or read the geeks' changelog while the app store can have the simplified changelog for non-coders. This is one of the reasons I think https://blink.sh/ https://blink.sh/ is one of the best iOS apps out there.
- saagarjha 6y ago
  The big issue is probably that the mobile platforms have significantly different monetization models and incentives. It’s possible to run an open source app, but you’re doing it mostly out of the good of your heart a lot of the time.
ggm 6y ago
Google is a serial offender
grishka 6y ago
That's just a consequence of the dreaded "move fast and break things" culture. Ideally, you should only be updating your app to add new features or to address issues that have arisen with an OS update or new hardware for example. And you should only be releasing new features when they're ready, not when current time matches a certain value. But for some reason you can't be doing any of that if there's money involved.
lubosm 6y ago
Oh yeah. https://twitter.com/lubosmedovarsky/status/1341342002403811328 https://twitter.com/lubosmedovarsky/status/13413420024038113...

241 points by jandeboevrie 6y ago

In an "app store" context, the apps don't serve you; you just generate content/engagement for them. The apps you're looking at don't WANT you to be informed because you might choose not to use them. These notes are just a formality standing in for forced automatic updates. Spotify on Google Play is particularly insulting. They basically tell/shame you that you should just always update without caring about the changes.

coldtea 6y ago
>In an "app store" context, the apps don't serve you; you just generate content/engagement for them. This is a non-sequitur. There are all kinds of apps in an "app store" context, and the apps I use serve me very well, thank you. I also don't generate any "content/engagement" for any of them. Whether apps have good changelogs or not is also not a factor of whether the apps are in an app store or not. You maybe meant to say "social apps" as opposed to "app store" apps.
- jrootabega 6y ago
  I guess I'm focusing on the ones at the top of the food chain, and the what I think is the predominant relationship in app stores, not necessarily the social ones. Eg the Microsoft ones in the article

henkdevries 6y ago

If an app is good enough, developers and managers and "agile coaches" and such don't stop, they start doing busywork. It looks like they're working and progressing, but all they do is scare users away with by removing features, breaking workflows and more horrible stuff. You're just making money for the shareholders, nothing more. They don't care about users...

dvfjsdhgfv 6y ago
In the case of many popular apps, it's a bit more than that: they're actively fighting what they perceive as bad actors, that is people trying to use their app not as intended, using their protocol outside of the official app and so on. In this case they have nothing to gain by describing the changes in more detail in the changelog.

johannes1234321 6y ago

With many apps an issue for changelog writers is that often behavior is tied to feature flags, which can be remotely enabled. Thus a new feature is rolled out in the app but only visible to some testers. Only after a while it's enabled for all users. Thus app release is independent from availability of a feature. That said "Bugfixes and performance improvements" is as useless as it gets ...

vbezhenar 6y ago
I wonder how those features pass Apple review? It's easy to disable those flags to get review passed and enable them later.
- robotnixon 6y ago
  I'm pretty sure that's what Fortnite did right before they got kicked out of the App Store. Before my company implemented IAP in a few of our apps we did the same thing, but decided the risk was too great. Getting rejected is one thing, but getting your account terminated is obviously a much bigger deal.
- JimDabell 6y ago
  You provide Apple with login details when you submit your application. Just enable all the features in advance for Apple’s test account.
- mackey 6y ago
  It depends on the feature. For things that involve material changes to your app or a feature that you don't want Apple to be surprised about, usually you will include user credentials in your submission that have that feature enabled and give them a heads up. If's a smallish feature, you don't usually sweat app review. It's obviously not a perfect system.
- saagarjha 6y ago
  You are supposed to list all the feature flags and explain how to enable them in your review notes.

mfDjB 6y ago

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.

temac 6y ago
It is bugfixes or performance improvements about things that exist, though.
coldtea 6y ago
>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 6y ago
  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 6y ago
  Logic Pro doesn't have server-side feature flags.

CJefferson 6y ago

The problem is often the "bugfixes and performance improvements" are a list of 60 things, and for almost all users "there are less crashes and it is faster" is all they would want to know. How many users want to read (OK, possibly people here) "On some versions of glibc, the 32-bit specialisation of memcpy which used SSE2 instructions had a bug when the memory being copied crossed the 2GB boundary, so in that case we now use our own memcpy" Or "Changed some internal lists to be only be sorted when they need to be rather than eagerly sorted whenever elements are added, which speeds up start-up time".

jandeboevrie 6y ago
Hehe I'd be happy to read such a changelog
- sltkr 6y ago
  I doubt you would. A large app each would have hundreds of changes like this. It would get pretty boring after the first dozen or so.
degenerate 6y ago
A lot of people here would like this level of detail, actually. But general apps are intended for the general population, which is why big orgs go for the minimum watered down version. It's more work and overhead if they confuse their users.
christophilus 6y ago
I prefer the detail. You could always make the first line: “bug fixes and performance improvements” with details following. Then people who don’t care can ignore the details, but people who do care can get an understanding of what the change is about. Deep understanding of a change is really helpful when looking through history or trying to make sense of why this particular line was changed, etc.
- bauerd 6y ago
  This is about app store changelogs, not commit messages

alexcroox 6y ago

I automate the app deployments for our team and “bugfixes and performance improvements” is the changelog because it’s totally automated on release. Yes the automation could grab something from the commit logs but I’m not confident I’d want to expose some of our commit messages. Also recent versions of iOS have further hidden away the update ui making it very hard to find for most users, so why bother taking the time to add them manually when 99% of your user base will never see them?

Kudos 6y ago
You can maintain a file with the current/next changelog in your vcs and pull from that. Works with automation, but is still curated.
kingosticks 6y ago
I think I'd argue it's not "totally automated" unless skipping the changelog generation step was the intention. In which case no need to justify that with any reasons, that's your (valid) choice to omit some documentation. We used to maintain our "customer-facing" changelog as we merged the associated code but that did create work when trying to release and finding some people had forgotten to provide an entry, which ultimately reduced release frequency. So now we don't include a changelog in the release itself, we create it after the fact and it's more of a "living" document hosted online (having to create another new release just because of dumb mistake in your latest changelog is really annoying). For those that are really interested, they can check the commit logs. For those less interested, they can wait for the online changelog to be written. It's likely they'll only have to wait a few minutes. Obviously the former is easy for open-source projects. I'm not convinced our new way is better yet but I'm willing to wait and see if the release frequency improves.
saagarjha 6y ago
> Also recent versions of iOS have further hidden away the update ui making it very hard to find for most users Thanks for your contribution to society, Apple Arcade.

twright 6y ago

One time I wrote simply “bug fixes” for an app update and it got rejected because the description was too short. I changed it to something more in the lines of “bug fixes and improvements” and it got accepted. I generally like writing changelogs for users but I also wonder how many people have automatic updates on and never read them.

jka 6y ago

As with many others here no doubt, I spent a lot of time in 2020 viewing diffs between library versions, reading changelogs, and tracking upstream bugs/features. Although I'll try to resist going on too much of a pro-FOSS rant, the change audit process is much easier for open source projects since you can read not just the changelog entries, but also the corresponding code to verify the claims. That helps with various things including developer trust - it helps you determine whether a project and authors use test coverage to reproduce bugs and prove their fixes, whether performance improvements are measurable, whether there are risky side-effects to look out for, and so on. Increasingly I think that these kinds of 'software due diligence' should become part of recommended software engineering workflows, and that makes me wonder whether some of the repetitive aspects can be automated. A genuinely user-focused, trustworthy app ecosystem would, I think, allow some of these 'change audit' processes to be visible to users so that they can make informed upgrade decisions, and to create a marketplace incentive for upgrades to be reliable.

deleted 6y ago

[deleted]

cesarb 6y ago

The worst of these is the "Google" app. For over a year, every single new version has the exact same four-entry changelog, which translating from Portuguese is something like: "enhanced search page appearance; new doodles designed for app experience; off-line voice actions, available only in the USA; web pages opened directly within the app". I have the slight suspicion that most of the almost weekly updates to the "Google" app do not have these four changes... for that app, "bugfixes and performance improvements" would actually be a better (more correct) changelog.

WesolyKubeczek 6y ago
Let me guess: the most recent changelog is getting picked up for every new version.

altitudinous 6y ago

I used to love posting detail about what I change in my apps. But now the text isn't really surfaced - folk have automatic updates turned on, and the text is deep in the app store now. My changes are mostly technical when I use the "bug fixes and performance improvements" text, but I tend to write more for the app store reviewers to let them know what is going on. I know they read it. In the end my audience of users are very non technical. I am authentic to them, that is the image that I sell my apps with, and I am good at it. So they just don't care that I've updated library X, or improved error handling somewhere, or I support Apples latest devices now. They do have faith that I am doing the right thing, and they write to me as if they know me, and I like that.

Santosh83 6y ago

These are changelogs for end users, not fellow developers. In fact I expect that even these "one line notices" will be dispensed with in future as the concept that any software or device requires an always-on connection to the Internet becomes fully normalised. Apps/devices will simply update and that's that. You won't be given any sort of option or toggle. Does anyone seriously ask the govt NOT to maintain a road or bridge? Such will be the case with software too. Individual freedoms and privacy have no future in the direction technology and society are going.

saagarjha 6y ago
You can be annoyed when someone comes by to bulldoze your house to build a hyperspace bypass, though.

magoon 6y ago

What it takes to get through app review

kevin_b_er 6y ago

Because you aren't meant to know what the changes are, just consume.

CM30 6y ago

Yeah, it is nice to know what the actual changes are, rather than a vague 'fixes were made' statement. Nintendo's update logs for games have to be some of the most hilariously vague in that regard, with many of the updates being just: > Several issues have been fixed to improve gameplay experience. But at the same time I guess I can see why companies and project creators don't go into more detail. Maybe the actual bugs fixed were so weirdly technical that most users wouldn't understand them at all, or care (if the user hovers over this button for 1/300th for a second, there's a 0.0001% chance their next message might not save properly). Maybe they (perhaps sadly) don't remember what exact things they fixed, since they fixed so many bugs. Either way some more detail would be nice for those that do care about this stuff.

rubyist5eva 6y ago
> Nintendo's update logs for games have to be some of the most hilariously vague in that regard On the flip-side, the changelogs for Super Smash Bros Ultimate and Splatoon 2 are some of the best I've ever seen.

blargmaster42_8 6y ago

Translateing : #$(ticketId) Resolved by $(implementation details) into something the end user understands IS HARD!

Rockslide 6y ago

> If that is all you're going to put there, then just leave it blank. Well, I would love to. Unfortunately neither Play Store nor App Store allow you to do that... so "bug fixes and performance improvements" it is, 99% of the time.

TrianguloY 6y ago

I also have automatic updates off and I really like checking changelogs to know what new things I can play with. And I don't mind reading 'bugfixes and performance improvements' ... but only if that's really what the new version is about. I like changelogs, but even for me a 'we fixed an issue where if you enter a 1025 characters text into the title textbox and press back twice while rotating the phone the app closes' is probably too much, but if you added a new option to increase the text size please say it, I don't want to check all the settings screens each time each app updates, and more often than not someone tells you 'hey, aren't you using this option?' No, no I wasn't, because no one told me. Are you a big company and you have automated updates? Why not have an automated checklist of changes too? I'm sure you have a 'roadmap list', so use it.

ChrisMarshallNY 6y ago

My changelogs are pretty complete. One reason might be that they are not automatically generated. I hand-edit each entry. Sometimes, I copy and paste the changelog entry into the last commit of the release (but I make sure to have a short, succinct initial sentence, as that is what shows up in Git browser history). The changelog may end up being a lot more "generalized" than the commit comments, though, as it's meant to be read by users. I appreciate the kinds of changelogs that you usually get with developer tools, where they are like encyclopedias.

deleted 6y ago

[deleted]

nudgeee 6y ago

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.

recrudesce 6y ago

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.

xyzelement 6y ago

I just looked at WhatsApp (one of his examples) and it has a detailed "what's new" in both the Apple and Android app stores that's listing three high level features. Sounds like the screen shot he took in September really was a bugfixes and performance release. So it sounds like these apps (at least, WhatsApp) follow a wise policy - tell the users what has changed that matters and don't drown them in irrelevant information. I had the same policy for my teams - tell users 4-5 new features/changes to workflow they are going to see and for g-d's sakes, do not drown that out by listing 400 irrelevant infrastructural changes we happen to be pushing out.

joshspankit 6y ago

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.

thomaspaulmann 6y ago

For early-stage startups, writing changelogs is also a great way to close the feedback loop with their user-base. We write detailed release notes at Raycast [1] to highlight feedback that we addressed. This way our users see that we care about their feedback and feature requests. [1] https://raycast.com/changelog https://raycast.com/changelog

awinter-py 6y ago

> probleemoplossingen en prestatieverbeteringen love 'bugfixes and performance improvements' in dutch

enra 6y ago

As a startup we write fairly detailed changelogs weekly [1]. For us it has been a major way to communicate all the new features and fixes as they come available to users. It’s also a good way for the team to celebrate their accomplishments. I was surprised to learn it also had helped with investors and generally marketing. Usually the person who was a major contributor to the highlighted feature of the week writes the changelog and then we look through our PRs to add anything that could be interesting. We don’t include things like “migrated x” “upgraded library x” if there is no visible benefit for there. Wrote about the lessons here: https://link.medium.com/9YuBV3dUIcb https://link.medium.com/9YuBV3dUIcb 1: https://linear.app/changelog https://linear.app/changelog

ulisesrmzroche 6y ago

Maybe like a couple bullet points, nothing too technical, but it’s a good spot to talk to your customers and make them happy. It does depend on the product though. I can see a developer tool maybe even just going so far as to putting out their internal change log, but for other customer segments, it’s best to keep it short and (hopefully) funny

phreack 6y ago

Worst offenders aren't even those. Some go as far as an 'Information not provided by developer', and the worst of them all - Netflix's 'You just worry about what to watch next.'. Irritates me to no end, I now only update manually and if there's no apparent benefit I just don't. Saved me from seeing some apps' changing icons into something awful, or hostile UX redesigns. It was a shame when Discord, who used to have some of the very best changelogs, turned into this practice.

deleted 6y ago

[deleted]

olivierlacan 6y ago

This is precisely why I started https://keepachangelog.com/ https://keepachangelog.com/ many years ago. Release convenience shouldn't come at the cost of properly communicating about notable changes for software users (whether developers themselves, or software consumers). Instinctively, developers reach for automation to solve this problem but this is an editorial problem for most software. Code changes very rarely map to notable changes for your intended audience. Even with rigid system like conventional commits, you can't entirely automate proper human-focused changelogs and release notes. You're going to have to clean things up and editorialize if you really care for your software users to understand what notable changes are included in a given version release. If you can't think of any, maybe you're releasing too often. If it's impossible to tell things apart because there are so many changes as another commenter pointed out, I think you have a way bigger problem.

rpearl 6y ago

when we build a new feature, it's gated by a flag controlled by the server. The app version with the feature is distributed well in advance of the intended rollout. So, we can't even put the new feature in the change log for the update that includes the feature, and the rollout won't be associated with an app update. All we can really put in the change log is bug fixes, and the circumstances that result in a bug can often be obscure and hard to describe in user-facing terms, so it gets summarized: "bug fixes and performance improvements". And for the play store and the app store, we have to put _something_.

p0nce 6y ago

The D compiler have had a great changelog since years and it has made a difference to popularize what went into an update. Each major change comes with examples, and it's great content. https://dlang.org/changelog/2.095.0.html https://dlang.org/changelog/2.095.0.html

baby 6y ago

That was not really interesting, so I'll start a related thread: - why is performance often favored instead of improving, refactoring, documenting, simplifying, etc. And how can we change that? - why are bug fixes so hard to track? Often developers fix something without marking it as a bug fix. And how can we change that?

rodone 6y ago

Bugfix: closed open single quote in title.

WalterBright 6y ago

We list all the changes: https://dlang.org/changelog/2.095.0.html https://dlang.org/changelog/2.095.0.html

mottosso 6y ago
Yes, this!

mottosso 6y ago

This topic and responses to it warms my heart. :) I've made it a habit for my current project to turn changelogs into blog-like material for the end-user. The kind of changelog I would like to see from other software, especially the kind I care about. For example: https://learn.ragdolldynamics.com/releases/2020.12.01/ https://learn.ragdolldynamics.com/releases/2020.12.01/

brokencode 6y ago

How much value does the average user get out of better patch notes? None, since they don’t even read the patch notes. So is that worth the time for each issue to write and edit a user-facing piece of documentation? Every little task like this is a waste of time and mental energy that slows down useful work. In my opinion, this is just not worth the effort.

bartread 6y ago
I too basically disagree with the author (for reasons I'll go into below), but I think it's worth unpacking a little further that high quality release notes can form an important part of your communication strategy with your users. Note: high quality. Many years ago I worked for a tools company where, for our less popular tools, user count would be in the thousands to tens of thousands, and for the more popular tools, it would be in the hundreds of thousands. Every single time we put out a release you could guarantee that a handful of people would ask for release notes even though we'd always publish them. Clearly people wanted them. Now I work for a company where our platform caters to two very distinct groups of users - one group internal, the other external. Particularly for the internal users release notes are hugely important in order to avoid disrupting their work and deliverables to customers. In both companies we've often had an "additional bug-fixes and performance improvements" item in the list. Why? Because people only have so much attention to go around: they're busy and, particularly in my current role and with our internal users, it's critical that we draw that limited supply of attention toward the most important changes. That's much more valuable than sending out an exhaustive document of every single change every time we do a release. We've found that if we supply exhaustive notes, fewer people tend to read them, and we get complaints that they're too long. As you've already suggested it comes down to ensuring that the release notes you provide are actually valuable to users. Together with other documentation and training materials, release notes can provide a useful jumping off point for learning how to work with changes and improvements to our software. (Not everybody reads them, of course, but having them does at least mean that when they inevitably ask for help/information, we can point them at the release notes as a starting point.)

einpoklum 6y ago

It is much more likely to see decent Changelogs on Free Software. (For many reasons, but including: "We added a new backdoor to satisfy government mass-surveillance program requirements.)

dasil003 6y ago

Contrarian viewpoint: I'm very passionate about this idea for open source software, especially things like ruby gems or npm packages that I might use as a dependency, but for some reason I can't muster the indignation to care about this for apps. Maybe it's because I care primarily that the app works and the latest version is stable. I'm generally not going in and considering upgrades to apps strategically, and even if I did I have no ability to see the previous changelogs let alone install those versions. If for some reason I want to avoid an upgrade now I'm living on borrowed time and need to start thinking about a replacement or carefully curate my backups so as not to lose access. Sure in a perfect world it would be nice to have perfect changelogs, but it's so far down the list of things I want out my apps that I place zero value on it.

richardwhiuk 6y ago

Those changelogs are likely wrong anyway. If you miss an update, you'll miss the intervening changelog. There's no ability to provide multiple changelog entries in the app store.

XCSme 6y ago

When I make performance changes I like testing the actual gains on the live server and add them to the changelog, something like: "Improved profile page loading speed by 25%". For reference: https://docs.usertrack.net/changelog#usertrack-3-3-1-11-december-2020 https://docs.usertrack.net/changelog#usertrack-3-3-1-11-dece...

lxe 6y ago

Thank you for choosing [app] - the best [thing] for [thing that it does]! We are committed to continuously improving the experience of bringing you the best of [thing that app does]. We update the app regularly so we can make it better for you. Get the latest version for all available [app] features. Love [app]? Rate us 5 stars!

grishka 6y ago
Meanwhile nothing at all changes with updates but there are hundreds of server-side settings that change all the time because metrics gotta grow. Eternally. Into infinity. And don't you dare get used to the UI.

sirsuki 6y ago

The FOSS community still campaigns the idea of Open Sourced software on desktops. Why then is the same not as popular in other platforms like iOS or PWAs? I truly wish I could visit github.com/[my-iOS-ap]/project and contribute or read the geeks' changelog while the app store can have the simplified changelog for non-coders. This is one of the reasons I think https://blink.sh/ https://blink.sh/ is one of the best iOS apps out there.

saagarjha 6y ago
The big issue is probably that the mobile platforms have significantly different monetization models and incentives. It’s possible to run an open source app, but you’re doing it mostly out of the good of your heart a lot of the time.

ggm 6y ago

Google is a serial offender

grishka 6y ago

That's just a consequence of the dreaded "move fast and break things" culture. Ideally, you should only be updating your app to add new features or to address issues that have arisen with an OS update or new hardware for example. And you should only be releasing new features when they're ready, not when current time matches a certain value. But for some reason you can't be doing any of that if there's money involved.

lubosm 6y ago

Oh yeah. https://twitter.com/lubosmedovarsky/status/1341342002403811328 https://twitter.com/lubosmedovarsky/status/13413420024038113...