5 ms·
Steve should of actually talked to Android developers of major apps before making these claims.
by minalecs 16y ago
Steve should of actually talked to Android developers of major apps before making these claims.
- Zev 16y agoHow about "minor" developers? By that, I mean people who would make an app as a hobby in their spare time. How easy is it for them?
- jeanvaljean 16y agoExtremely easy. You can quite literally start from not knowing anything about Android development and, in an evening, have a simple app up in the Marketplace. ...and before anyone responds with "well, that's just going to lead to a bunch of bad apps in the store," I ask you to count the number of fart apps in Apple's App Store. Though I'm sure they're all quality fart apps...
- Zev 16y ago...and before anyone responds with "well, that's just going to lead to a bunch of bad apps in the store," I ask you to count the number of fart apps in Apple's App Store. Though I'm sure they're all quality fart apps... I typed "fart" into iTunes and hit search. 180 results per page and it gave me 5 pages of results. Thats 900 apps[1]. But, not all of the apps are fart apps. There's apps like "Vuvuzela Joke" or "Nerdoids"[2] that likely have "fart" as a keyword. So, the number is slightly less than that. And thats with the irritation of codesigning and iTunes connect. I don't want to so much as think about how many fart apps there are available for Android, if its that much easier to get an app into the app store. Although.. it might be a lower number since the (paid) Android app store isn't available in as many countries.. But, you probably didn't expect me to go and count, did you? ;) 1. In the US app store. 2. Picked at random from page 5.
- evilduck 16y agoProbably easier than iOS, which has the prerequisite of running OSX. A "minor" developer without a Mac needs to buy one or build a hackintosh, both are significantly more work than downloading Android's SDK. And more people know Java than Obj-C, so there's that too.
- foobarbazetc 16y agoWhy? Developing for Android is a pain in the arse, especially once you're done and testing in the field. There are hundreds of devices, all different, all with their own bugs and all running different versions of the OS to deal with. This is J2ME all over again. That doesn't mean it's impossible, it just means it takes longer. It also means you need to go out and buy a tonne of development/testing phones. All of the above might be okay for people with money and/or investment, but makes it difficult for small developers. Let's not even begin to talk about the Android Market, supported seller/buyer countries, currency display, return policies, etc, etc. Compare that to iOS -- Apple rolls out an update to the OS, it works on all devices, and they're all identical. There's far less testing required (version N, N-1), and far less hardware investment too. You pop your app up on the App Store and it all 'just works'. That's what Steve is talking about -- integration vs fragmentation.
- jinushaun 16y agoDeveloping and testing on Android wouldn't be so bad if the damn emulator was actually usable. AVDs sound great in theory, but useless in reality. A hobbyist can't afford to buy a couple of dozen phones to test out an app. No wonder Android Market is full of comments about apps not working...
- jeanvaljean 16y agoDo you have an app in the Marketplace? I'm a developer for a very large Android app that touches more system components than most and we have no place in code where we check for OS version and exactly 3 places where we check for a very specific (bad) phone. "pop your app up on the App Store" -- after going through Apple's gate. In the Marketplace, we deploy on our schedule, not Apple's.
- nodata 16y agoWhat's the bad phone?
- codingthewheel 16y agoYeah, fortunately this is not how software works in practice. The best example is probably the PC market, which is fragmented to such a degree that the hardware permutations are uncountable -- and yet Windows, Linux, other major operating systems and applications all manage to deliver stable, consistent user experiences. The situation with Android is parallel: lots of different hardware, but basically still a "write once, run everywhere" environment. (Everywhere being any phone with a legit Android environment.) Similarly to when you're developing on a PC, you occasionally need to know something about the specific hardware or version you're running against, but more often than not, you just code, and it just works.