If you need to fix a major bug then yes, get that update out quick.
Never updating an app is probably a bad idea.
But beyond that it gets a bit complicated.
Is it good to release an update every time a small fix is made?
Should you release regular updates on a predictable schedule? Even if one of those updates contains only a very minor fix? What if you break that schedule and your users have come to expect regular updates?
If the app alerts the user when new versions are available, should this have an impact on how often you release? It might make the user more aware when they stop?
If the app includes a version history, is there any value in including the release date of each release? Or a string reason not to?
What if the app is a relatively dumb client but you update the server side logic on a regular basis (either to fix bugs or add features), should this be informed to the user in some way? How?
Is it worth planning, in advance, an update shortly after you launch? As part of a promotional campaign which aims to demonstrate how responsive you are and how you listen to your early customers?
How long is too long to leave between releasing an update?
Is it ok to release an update with just bug fixes and no new features?
Of course it'd be great if you never had any bugs to fix...
How much functionality do you need to justify calling it a major update?
Obviously a new version must be tested before it should be released. Do apps built with a large amount of automated testing get updates released more often? Got any examples?
Similarly, do apps built with automated release tools get released more often? Because it's easier to? Got any evidence?
This is a potentially difficult, and controversial(?), area. No doubt some people have some strong opinions.
I'd love to hear your thoughts.
It'd also be good to know that other people releasing apps are thinking about this issue...