There's the time in a life of every good developer to deliver an application. And a good developer not only ships but also supports. It's great if you can add or tweak some features, but if not, there's also one other category which causes us to update our apps.

Every piece of software has bugs. Always. As smart people say:

Ship the right bugs.

Great developers can do just that. They know their product will never be perfect. There's a place and time to just release something to people, let them work with it and give you feedback (and money). No "one more day/week" will make that big difference. It won't push your product that closer to perfection. It's not worth delaying the release. And even then - it will always have some bugs.

It's an important lesson. You can hear this when listening to experienced developers, entrepreneurs and product owners. But there's a thing which a lot of developers has to learn, but it isn't stressed nearly enough. Release notes. Here's a screen of my iPhone from this week:

* It's modified to concentrate on the issue.

Most of those messages don't mean anything. I will say even more. You could as well write "Added some more bugs". It would give the user about the same amount of information and it would be closer to your state of developer's knowledge.

Writing about fixing bugs and improvements is meaningless and lazy. It's not like I think that you added some new bugs on purpose, unless you state otherwise. In general, I expect you fixed some things, maybe added some new features. If you modified your code quite a bit, you probably added some bugs, you're not aware of yet. But with those "Bug fixes", it's a whole other story.

You know what you fixed. And what's even more important - that's something which your users are actually interested in! That's what can even make them excited about your software. And with App Store dynamics - that's how you get organic, good reviews, without ever asking for one.

It's your only, non-intrusive way of communicating with your users. No popup windows, no special code, libraries. You just have to state them in submission process. And it's something your users choose to read. On iOS they actually have to tap on a small label inside App Store, to read what you wrote to them. If they done so, they expect something more specific than just "Tons of bug fixes" or "Improvements". If there are a lot of them - tell about them! It shows how much hard work you did and how much you care about your client's experience and feedback.

It changes how they see your update. From "Oh. They fixed something" to "Yes! They read my e-mail and fixed my problem!". It actually carries some message, some information about your hard work.

So remember - next time you're writing a Change log or Release notes, be more specific. State those changes, fixes, improvements. If you think some of them are too technical, say which view or which feature got better. Maybe how. If there are a lot of them, choose the most important ones (or release more often?). Don't be lazy! It can sometimes be as important as the fix itself.