🐛 Do You List the Bugs Fixed in Your App Store Release Notes?

I must admit, I’m a bit of a stickler for reading the release notes for updated apps on my iPhone. I enjoy seeing the red badge count on the App Store icon and I usually go in and check for any interesting changes in the apps that I use, even if that ends up being a bug fix or maintenance release. That’s not normal behaviour is it? Some people won’t care much either way and that’s fine too.

If developers have added new few features to an app there will usually be a song and dance about it and the new functionality will be described in the ‘What’s New In This Version’ text. However, what about maintenance releases? These are the less exciting releases of apps which fill the void between the major releases. These will be your v2.2.3s and v2.2.4s point-releases: the bread and butter of releases in an app’s lifecycle. But don’t these versions deserve some love too?

In fulfilling my compulsion to read the release notes for the apps on my device, I’ve observed 3 main approaches. Let’s take a look at these in more detail.

1. “Bug fixes”

First up, we’ve got “Bug fixes” and its slightly more attractive sibling “Bug fixes and performance improvements”. This is the no-fuss, no-nonsense “get the job done” approach. I’m not a fan of this style of message because it is not very informative to the end-user. If your app had known bugs then some of your users will have been affected, even if it was just a handful. Allow me to elaborate:

Bug fixes.

Should we care about updating to this version? The release notes are provided so that app developers can communicate the changes in their app to the end-user, otherwise this would not be a mandatory field when submitting an update to the App Store. Personally, as a user of an app, if I’m affected by a bug I would find it interesting to know whether or not this bug has been fixed. Each time I see release notes which simply say “Bug fixes” I’m left wondering what these bugs might have been. The following questions spring to mind:

Are the bugs so trivial or obscure that its not even worth mentioning them?

Fixed an issue where the the Send button would turn a slightly different shade of red if the device is held upside down by someone named “Dave” during a leap year.

If this is the case why was this worthy of a stand-alone release in the first place? Presumably trivial bugs could just be rolled into a more meaningful update, perhaps when some newer features or more important bug fixes are ready to be rolled out. Hmm, I’m not convinced! What else could it be?

Are the bugs so bad that the developer is ashamed to itemise them?

D’oh! Fixed an issue where the app would crash every single time you try and open it. Oops! Fixed a critical issue where we accidentally sent all of your personal information to malicious third-parties.

Could it be that there are simply so many bug fixes included in this release that it would be insane to include a description of them all? We’ll never know because this developer has chosen not to reveal what’s actually been fixed!

A less critical opinion is that there might be something completely benign about the changes (e.g. updating a third-party library):

Updated ThirdPartyLibrary B to version 0.16.1.

OK, so this one is fair enough. There can be entirely legitimate reasons for needing to ship an update to an app in order to satisfy some technical requirements. For instance, you may be updating to the latest version of your analytics provider which addresses some issues with reporting metrics. This doesn’t directly impact the end-user and it can be difficult to summarise this as a ‘What’s New In This Version’ style message when there really is nothing interesting or useful to tell the users of your app.

In my opinion, whatever the reason may be I consider a simple “Bug fixes” message to be fairly lazy on the developer’s part and I endeavour not to do this with any apps that I release myself. However, there is an even more sinful style of release notes.

2. My CI Server Shipped This Build So I Didn’t Have To

The ultimate in lazy release notes. Sit back, grab a beer and put your feet up because no human interaction is required to ship this build to your customers! This will almost always take the form of a short statement explaining that this is a periodic app update. It will never explain any of the changes included in the release and will almost certainly have been shipped automatically by the developer’s continuous integration server. Take this example, borrowed from the Facebook Messenger iOS app:

We update the app regularly so that we can make it better for you. Get the latest version for all of the available features and improvements. Thanks for using Messenger!

I like continuous delivery. However, is there an excuse for not including any indication of what might have changed in a new version of an app? Any decent software project management solution will likely include some sort of release management which can provide a breakdown of the changes to a piece of software between any given versions.

As a developer, there are many advantages in automatically shipping updates to your customers, especially if you intend to do so frequently and on a regular basis. However, this style of release notes does rather take the human element out of shipping your software.

And finally, we have ‘old faithful’.

3. The Detailed Breakdown (Why You Should Care About This Update)

The following example is an excerpt from the What’s New In This Version text for version 1.0.4 of Guides By Lonely Planet:

Fixed an issue some customers were seeing where they couldn’t access Guides they’d downloaded once they turned on airplane mode Fixed an issue where some offline map downloads would appear to get stuck and would not progress Fixed a bug where we were erroneously showing Las Vegas as a City Guide

This is a clear, yet succinct explanation of the bug fixes included in the latest version of the app. This style of release notes is informative because it details the specific bug fixes and changes contained within a new version of an app. An end-user who may have been affected by one of the bugs may benefit from knowing that the pesky bug has now been resolved. More importantly, the developer shows us that they care. After all, there was a reason for shipping this build in the first place - wasn’t there?

So What?

It is entirely up to each developer to decide how they wish to present the release notes for their apps. We’ve taken a non-exhaustive look at 3 styles of app store release notes, ranging from the uninteresting “Bug fixes”, the robot authored “Automatic update” and finally the informative defect breakdown.

Ultimately, the end-users may not even be reading your release notes - a lot of users may have automatic updates turned on - but it still seems prudent to take advantage of this line of communication between developer and customer in order to demonstrate your commitment to the software.

Which style of release notes do you prefer to use for your app updates?