1.) Squashed some bugs
2.) Made some improvements
3.) Mostly ‘under the hood’ work, but important nonetheless
Not the most useful release notes ever. Very funny. I guess the release process says there has to be something there or you can’t do the release.
That’s how YouTube normally explain theirs, very similar style anyway.
Strava doesn’t even say anything in their updates.
Yeah, I hate that. I will avoid updating any apps that don’t have notes if I possibly can.
Simple release notes were funny a decade+ ago when I first saw one. Now they are annoying. Why not write “Small fixes and improvements, and yes despite the apparent slow pace of development we really do have full time developers working on this product.”
No release notes on the latest iOS beta.
Whenever a colleague retires I always ask if I can use their name as a pseudonym in all my comments for the next year. I have had the good fortune to work with a couple colleagues who, like Euler, continued to publish well after their passing.
I agree. Why don’t companies have a link where the publish more in depth release notes. The under the hood changes might be something my specific trainer is suffering from.
Most release notes could just say
In their market it would be very easy to give away details that a competitor app could leverage, so playing the “vague” approach is safe I guess. I would hope however that if there was any significant reason to add specific details, eg, security related, that TR would call it out.
Depending on the length of the dev/release cycle a complete set of change notes might be huge but having a link to a release notes page takes care of that. There’s also changes to commercially sensitive code that a company almost certainly won’t want to divulge.
That said, something like:
Doesn’t divulge any sensitive info whilst actually stating what’s been fixed.
TR use libraries like React so there’s a good chance that there are changes associated with updates to those.
That’s an excellent point! It could be that’s the case. It could also be that when the cat’s away the mice will play. Ha! 
This would also be extremely helpful if you’ve reported an issue to know if it’s fixed in a specific release. The other way I’ve seen this done is to say the release fixes specific issues, and just list the issue number. But this would require TR support to give people issue numbers when they report problems
When you raise a problem with support you get a reference number but the chances are that it doesn’t refer to a bug number in the bug tracking system or a commit in a version control software like Git.
The last beta in testflight had even better notes (at least initially, I think they went back and edited slightly after pushing it out)
I laughed a little, but it doesn’t truly bother me in reality.
Good news everyone.
Were the improvements to the bugs or to something else? 
Today’s were much better and kudos to the dev team for getting these updates out very regularly. Nice to see.
Good to hear, from my point-of-view its quid pro quo. When I take the time to carefully document and submit an issue, I expect my vendor to take the time to document fixes. All of the software developers I talk with use a system like Jira to track issues, and that makes producing release notes fairly easy.
Also, “possibly re-introduced a bug that was fixed previously.” 
Don’t tell people about problems they weren’t impacted by is my motto.
My stance on that is for the app to provide a link, like when I want to know the details of macOS or iOS upgrade before applying it.
