Hacker Newsnew | comments | show | ask | jobs | submit login

You can talk about those differences, and of course it's not a 100% analogy, but I think his main point was about the market share and the ecosystem. If Android ends up with 3 billion users in 2015, and iOS only 1 billion, as predicted (also with the whole of Windows at 1.5 billion users, from 1.3 bn now), I expect most developers will be wanting to develop for Android first by then, and it should be their #1 source for income, too, simply through sheer numbers of users.

"I expect most developers will be wanting to develop for Android first by then"

I doubt it:

- Owners of Android handsets on average have lower disposable income than owners of iOS devices. On top of that, a lot of Android phones are in developing countries.

- Most Android handsets run an old version of the OS and will never be updated, thus limiting the choice of APIs that developers can use.

- Many Android handsets are used as dumbphones, their owners will never download apps.

- There is not one main app marketplace for Android, and not all Android users can use the same marketplaces.

- Few Google Play accounts have credit cards linked to them. Amazon is in a much better position, but Apple still has more credit cards on file.

- Google makes developers pay for chargebacks.


For-sale apps are a dwindling market anyway. All the contract work I get now is for companies that want an app as part of some larger business and are almost never direct revenue sources.

For this increasingly dominant app category reach is what counts.


Dwindling market based on what facts ?

I haven't seen any evidence of Apple's App Store revenues dropping markedly. Pretty sure the market would be VERY concerned if that were the case.


Revenue is skewing ever more heavily to the handful of big players at the top. For the typical developer profitability is a moot point.


Having done corporate grade mobile work, there's no question of which platform is easier to develop for. On Android, not only do you have to simultaneously target in some cases four or five different API levels, you also have to hit several combinations of screen dimensions and resolutions. The documentation for Android is also lacking in comparison to the iOS docs. The android SDK, though comprehensive and generally very high quality, suffers from the same complexity problems arising from issues related to fragmentation.

Remember though, most of the developers who are doing work that actually matters on mobile aren't doing it because they want do, they're doing it because a corporate strategist thought it would be profitable use of their time.


I haven't found this to be the case at all. With the compat libs you can pretty easily target 2.3 and 4.x. And the dynamic layout issues are more than offset by the much greater flexibility of Android's layout managers.

An iOS app I'm working on right now has been a nightmare in comparison because we had to port our layouts to the i5 form factor but can't require iOS 6 just to get autologous. Apple really blew that transition.


Still: how many currently deployed devices running iOS are you going to be QAing that application on? Two, maybe Three? How many versions of iOS are you going to be seeing on those devices? One or two most likely, iPhone users tend to upgrade with their software with much more conformity and faster. Compare that to Androids upwards of fifteen (and growing) widespread devices, and a heinous amount of API levels in the wild. That's one of the more objective factors which make Android easier.

Also, you can say that the API level differences don't matter because they are hidden by compatibility libraries like The Support Package, but the truth is that those are just the newer APIs re-implemented against the old interfaces. You pay for that extra abstraction with wasted cycles and bloat, and it's an ugly solution. Even still, those libraries aren't perfect: there have been subtle bugs or incompatibilities introduced by their use which are notoriously hard to find. Finally, even if the newer APIs are present on the device, The Support Library will still be used (last I checked, though I think they are working on this).

Less objectively, it's a matter of preference. Some people just prefer objective C to a JVM compilable language.


I have had way more mystery bugs on the 3gs than I have on any Android phone.


Weird. I found Android to be a nightmare.

The emulator is atrociously slow and every manufacturer seems to have different implementations of UI controls meaning it is expensive and time consuming to test.


Run one of the x86 images and the emulator is plenty fast. It takes a while to start up but after that the speed difference compared to the iOS emulator is negligible.


Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact