Missed opportunities in changelogs

4 different ways of writing changelogs for your mobile apps

Last updated on 5 July 2022. Created on 30 May 2021.

I'm one of those people that go to their App Store and for each update available reads the content of the description also known as [changelog](https://keepachangelog.com/en/1.0.0/).

I have identified these to be the common styles:

  1. Bland version: the ones with something generic. Examples: “Bug fixes and performance improvements”. Or my favorite “Information not provided by developer”. Usually it's the same text copied and pasted with each new version.

*A new variant of the bland version appeared, the one where there's a simple link inserted.

  1. Too-much-info version: the one where very important stuff is announced in the change log (new features, something that might stop working, know bugs that are still not fixed etc) and that information is not part of the actual app itself.

  2. List of what is new and what is fixed: a concise list of additions and fixes. IFTTT is a good example here.

  3. Right amount of info and a touch of personality: interesting, fun ways to let users know about what has changed.

For me, style #1 is annoying. But I feel that #2 is actually wrong. Time and time again I was able to use new functionalities because I've read the log, while my friends had no idea about them since the application didn't highlight anything in any way.

I consider the changelog of an app to be one of the touchpoints in a user's journey. So I believe that the culture of a company should be felt there as well.

That's why I really like the 4th version.

A few companies are doing this right: Booking, Slack, Google, Dropbox and others. I've only listed the ones that are more popular, but there are others out there paying attention to their users in all the right ways.


If you enjoyed this article and think others should read it, please share it on Twitter or share on Linkedin.