Why? 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.
Yeah, 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.
Mobile is a different ball game. To start with, while hardware is more varied it's also got far more standardised input hardware - there's a keyboard and there's a mouse and you can rely on that being the primary input.
On Android there will be a touch screen, but it's size, resolution and accuracy will vary. There may be buttons but their quantity and makeup will vary.
The second factor is that you cannot get away with bad UI as much as you can on the desktop. On the desktop it's frustrating but survivable, on mobile it's a death knell.
It'd be more accurate to call it write once, run poorly everywhere.
Edit: insert irony about shocking mis-post blunder due to an interface quirk of my Android phone here.
I suspect that it's more realistic to compare Android development to PC development, say 5 or 10 years ago than now. When I was developing games 10-12 years ago there was a staggering array of different displays, processor speeds, internet connection speeds, colour depths etc etc, whereas now on pretty much any PC you'll have true colour, decent display, decent connection etc. I suspect that game developers still have to wrestle with capability differences more than the rest of us, but for "normal" applications any PC is good enough these days. Windows and the related drivers are also much more stable and consistent now. I don't think Android is there yet, but I suppose it will be within a couple of years.
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.
Developing 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...
Extremely 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...
...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? ;)
Probably 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.
