4 ms·

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

by umsm 13y ago

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.

ajross 13y ago
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?
- umsm 13y ago
  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.
jamesjguthrie 13y ago
> 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
- umsm 13y ago
  I believe you are referring to the app store guidelines. The article mentions the android market place.
  - jamesjguthrie 13y ago
    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.
    - umsm 13y ago
      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.
KirinDave 13y ago
> 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.

by umsm 13y ago

ajross 13y ago

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?

umsm 13y ago
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.

jamesjguthrie 13y ago

> 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

umsm 13y ago
I believe you are referring to the app store guidelines. The article mentions the android market place.
- jamesjguthrie 13y ago
  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.
  - umsm 13y ago
    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.

KirinDave 13y ago

> 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.