Hacker News Reader

Comment by umsm | Hacker News Reader

I don't agree with this.

Basically the author thinks that you can test the market if a particular idea / app is worth making by releasing on Android first. The problem is that the android users will most likely hate the UI and the bugs as it will probably be thrown together.

When releasing an app on iOS, you don't have to include ALL features, you can release an app that is well designed and functions well with limited functionality. Then add features as you need to.

That's what we did when we released our app. We released for iOS first and then for android, but we gradually added features as needed or wanted.

View on HN

> The problem is that the android users will most likely hate the UI and the bugs as it will probably be thrown together.

This is where your argument breaks down. It assumes that because you are on Android, you app is shoddy. That need not be the case. Android gets a bad rap for being "hard to develop for", but that's only the case if you try and hit the entire 2., 3. and 4.* userbase.

If you limit yourself to 4.*, the dev work is very comparable. It's just a lot of people are utterly convinced they need to put in 2-3x the work to pick up that 40% of the market.

> you don't have to include ALL features

You sure do have to include a lot of features though. You've no chance if your app is a simple one because you'll get hit with one of these:

2.12: Apps that are not very useful, are simply web sites bundled as apps, or do not provide any lasting entertainment value may be rejected

I believe you are referring to the app store guidelines. The article mentions the android market place.

Of course I'm referring to the App Store as that's what your comment was about. If you want to publish on the App Store you need to make sure your app can't be thought of as 'limited' as then the reviewer could reject it, citing rule 2.12 - whereas on Android you can release almost whatever you want.

Ah, I understand now. I was referring to minor features that will take a long time to implement. I understand that you can't release just a splash screen.

In every product, there core features, then there are minor / convenience features. Let's say you have a "search" feature. That is a core part of the app / product / service. Some features that you can probably put off are: "advanced search", "refinement search", or even "sorting results". All of these are convenient, but you may want to have the app in store without these features.

I'm not following your arguments at all. Android apps must inherently be buggy and "thrown together"? Android apps must "include ALL features" before release?

From what I understood from the article:

- You can iterate quickly on android. If you notice that people don't care for your app, you can stop at the splash screen I assume. Or stop when you've added enough features that and yet no one is downloading.

- When you release on android, it's almost instant. This means that you don't test it as well as you should because you know you can always patch it tomorrow.

Reply on news.ycombinator.com