4 Answers
4

If your working on a big update but don't want to give the impression of inactivity, write a blog post about it so that your customers can see that you haven't been hit by a bus.

Other than that, I push fixes/updates as soon as they are available and tested.

Severe emphasis on the and tested part. Lots of people out there have the one-line-fix mentality where they think fixing one line can't POSSIBLY break the code. Pushing changes that break your app are, to put it lightly, not desirable.

Edit: And please don't push an update just for the sake of pushing an update, there is nothing wrong with your app not having been updated in awhile if it isn't riddled with bugs. I frequently work on more than one line of development at once, if I'm implementing a feature and someone files a bug report, because I'm the only developer I put the feature on hold and fix the bug.

Balance the level of desire for a new feature with the perception of how long it should take to develop. They may not be realistic, so you have to provide a little education. Sounds like you don't have much interaction with your users. If you do, they would have a better answer to this question. Otherwise, it depends.

It all depends on whether or not a new release actually does add value to the existing software. There might be situations, where the software simply does everything it's supposed to do and there really is no need to add feature after feature, after feature. Hence, the release cycles might be quite large (just fixing bugs, adding an optimization here or there but nothing really special).

On the other hand if the app is evolving regularly, then release a new version as soon as it's ready, meaning there actually is something new for the user that adds value.

Don't release a new version just because you think it's time to do so - in the long run the users won't be happy. Nobody likes to install a new version just for the sake of updating.

Apple has recommendations on iTunes Connect regarding recommended maximum update frequencies (sooner for bugs that seriously impact users, much less often for minor tweaks).

Don't spam the App store with unnecessary frequent releases; but, at least for marketing reasons, don't let your apps appear to be stale compared to competing apps. You can check on various site (such as appshopper.com, et.al.) on how often other apps in your category are updated, and see how you compare with your app's competition.

You may want to update your app after recompiling and retesting on each new major (or even minor) release of the iOS SDK. Apps that aren't updated, after a new major iOS release becomes the majority version in use, often appear suspect to many potential customers.

The App store update process is not just for bug fixes and new features, but is also required for updating screenshots and some of the important App store metadata, although one does have to bump the app version number when one does this. If you find that your screenshots or keyword choices are hurting your app's popularity and sales, you may be required to submit a no-change bumped version number update to fix this.

You may also want to update some unimportant app just before any deadline for a major app release just to make sure there isn't some glitch or change in the app submission process (new contract requiring a month for the company's lawyer to approve clicking upon, your certificates became moth-eaten, or some such...).