Did we at any point say it was a nightmare developing on Android? It wasn't. | Hacker News Reader

Did we at any point say it was a nightmare developing on Android? It wasn't.

wired.com

20 pointsminalecs14 comments

Steve should of actually talked to Android developers of major apps before making these claims.

How 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?

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

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.

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.

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.

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

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

What's the bad phone?

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.

Disclaimer: I've never written an Android app.

CEO states rival product is worse than the one his business sells, Film at 11.

How hard is it to run spellcheck before publishing an article for half a million readers?

  compile Android on a home Linux machin--a way

Reply on news.ycombinator.com