6

I wanted to know the experiences others have about doing the Agile way of "Release Early, Release Often" with iPhone and Android Apps. Its not a problem with webapps as the update happens at the server and user does not have to do anything specific for updates

It may not be a big problem with Android, as the approval process is smooth compared to iPhone app store.

Can someone share the experiences/suggestions/examples they've for releasing early and often to Android and iPhone markets?

Improve this question
1
  • I could see some answers with respect to to iPhone. Can someone share the experience with Android?
    – leenasn
    Nov 2, 2011 at 7:49

5 Answers 5

Reset to default
6

There are two differences between releasing on your own or releasing through Apples App Store:

  1. It takes 1-3 weeks to get approved for updates. Often one week, sometimes two, occasionally three.
  2. You run the risk of having your update rejected for one reason or another, thus having to redo the release again. Approving rejections is quick (1-5 days)

So all this makes it impossible to make controlled releases quicker than three weeks. You are forced to plan your releases and deadlines much more thorough.

Improve this answer
2
  • can you please explain it a little more? Couple of questions: 1. Did you mean to say the "Release Often" will not work very well? 2. Even for an update of released app, it will take 1-3 weeks?
    – leenasn
    Nov 2, 2011 at 7:42
  • Updated the question a bit.
    – Martin Wickman
    Nov 2, 2011 at 10:13
4

Be aware of the annoyance factor of very frequent releases. It's one thing to update your web app daily, or even more often, so that users automatically see whatever small changes you've made since the previous release. But if a user has to take some action, however small, to install new updates, frequent updates quickly become tiresome.

I've encountered apps that seem to need constant updates on both iOS and Android, and it leaves the impression that the software is of low quality. Changes from one version to the next are often so small that they're hard to notice, so as a user I assume that all those updates are mostly bug fixes. And if the changes are noticeable, it makes the app feel less predictable, less familiar.

I'd say that if your app isn't solid enough to make it available for at least several weeks, consider waiting to release until it is. I know that sometimes bugs aren't discovered until after release, and of course you should fix significant ones ASAP, but if that happens more than once in a while you should look at ways to improve your testing process.

Another way to look at it is that every time you release a new version of your app, you're saying "Hey! Look at this!" If you do that too often users who might have been impressed by all the new stuff you added between version 1.0 and 2.0 will instead be bored by the minimal differences between 1.9.6 and 1.9.7.

A better approach is to design your app so that you can update content as often as you like without updating the app itself. If you know that you might want to change the app's appearance around various holidays, for example, build your app so that it can download themes from a server instead of updating the app before and after the holidays.

Improve this answer
3
  • 2
    well said, I've always been extremely wary of the whole "release often" and "release early" idea (in any context). You don't want to release when something doesn't offer full functionality, and you don't want to release for trivialities. So 1.0 is fully functional, the next public release has major improvements and/or fixes critical problems. Don't make a new public release just to for example change the font colour on a button.
    – jwenting
    Nov 2, 2011 at 14:18
  • 2
    I have to back this up. I haven't been developing for a year or so and won't be actively developing anything for another 6-12 months. It's amazing how your point of view can change. When I see apps on my Droid that have updates every week or two, I start wondering why they need that - They can't be adding new features that quickly, so just how buggy is that code they release so quickly? And, honestly, it's a major PITA to keep updating. I've stopped using apps (even ones I've paid for) and switched to others if I had to update an app too often.
    – Tango
    Nov 2, 2011 at 14:40
  • Thanks for your comments. Especially the last point was very helpful i.e about how to change the themes without updating the app.
    – leenasn
    Nov 4, 2011 at 9:54
2

I'd like to debunk this "Apple's approval process is like running a gauntlet" business.

No app I've ever submitted has taken more than seven days to be approved.

In my experience, if you're careful and aware, you'll have no problem getting approved. Half a million apps or so have been approved, and my experience is, you really have to try to not get approved. And of course, whining on a blog about it is a good attention-getter and leaves people afraid and concerned, rather than just being professional about the requirements of the platform.

My policy with iPhone apps IS to release early and often. The only exception is if there's some big, game-changing feature the app has that you don't want to show your hand about. If the marketing plan calls for something splashy on release, you don't want to have put out a crippled early version of it first. That's probably true on all platforms.

Improve this answer
2

Release Early

This is bit of an issue in case of Android/iOS Apps if your main channel of distribution and promotion is going to be Market/AppStore. If you release too early with some glitches (especially force-closes) you'll have some unhappy users. Just a few unhappy users can get your initial scores quite low, which will seriously hurt your chances of the app showing up high in search results.

Release Often

As you already said, not an issue with Market. With AppStore it has improved a lot, trusted apps get their updates approved withing few hours.

Improve this answer
0

I've got experience with Android. Android supports the "release early and often" methodlogy. Ususally, your program is updated within minutes of adding a newer version of the apk.

However, one problem I found is fragmantation. Believe it or not, there are tons and tons of websites that directly scrape the Android Market and thus duplicate its contents. About 60% of the users of your app may download it from sources other than the Android Market. All these other markets scrape the Android Market with different time intervals, or may only scrape it once for each app, just to add it to their database and come up in search results. As a result, at any given time users can download a randomly selected past version of your app based on which website or market they get it from.

Because of this duplication of content going on, I haven't tried setting up multiple accounts on multiple markets and release on them simultaneously. The few times I tried, I found that I couldn't add my app because it was already added...

Improve this answer
1
  • Thanks for the really useful comments about the fragmentation issue what you are talking about. I was not thinking about that at all. But am not clear on how will it affect the "Release Often" concept. Is it that the chances of people downloading the wrong versions is more when you release too often?
    – leenasn
    Nov 4, 2011 at 9:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.