The Android toolchain is also significantly less developer-friendly than the corresponding iOS toolchain.
Plug in an iPhone, and (after jumping through the byzantine code-signing system) you'll be able to deploy development code to it (from an OSX environment). If your app runs on one iPhone, it probably runs well on another, barring some screen geometry concerns.
Plug in an Android device, and you might need to search around to find a manufacturer-specific toolset, and/or navigate secret menus to enable debugging (like "click this menu item that doesn't look like a button seven times"). You might also have to worry about ancient devices that can't be updated to a modern Android version, and have egregious platform bugs. Comparatively, it's a mess.
'Plug in an Android device, and you might need to search around to find a manufacturer-specific toolset, and/or navigate secret menus to enable debugging (like "click this menu item that doesn't look like a button seven times"'
Sorry I need to call BS on that. Developing on your android device is approximately a thousand times easier than the entire Apple developer/certificate/code-signing dance. Running the app under debugger is also a single button click experience. To top it all, all of this is free and runs on multiple desktop platforms (Linux, windows or OSX). The relative shortage of Android developers in SF and NYC is much better explained by the original article than any sort of difference in ease of starting out in either platform.
That's extremely exaggerated. What phone did you need to find a "manufacturer-specific toolset"? I'm not even sure what you are referring to. In fact starting on Android is significantly easier than iOS. Enable debugging, plug phone in and you can start debugging your apps on the phone.
Don't even get me started on sharing apps to testers. iOS is just a nightmare without using something like TestFlight.
You can't even get started on iOS without having a Mac, a $99/year subscription and worrying about creating app ids, profiles and other strange things through the developer portal.
Some phone manufacturers (like Samsung) ship with an incompatible, JSON library. You have to enforce the dependency against the official library if you want your app to not fail mysteriously.
Nothing is as bad as Apple's brain-dead method of tracking files in its projects. They create UUIDs for each entry, instead of doing something more file-specific. This results in merge conflicts when more than one person works on a project. Poor design.
I haven't run into that issue but I am not surprised. Anything goes with Samsung phones.
With Gradle and Maven support I've found it really easy to manage dependencies to third party libraries. Personally I use Jackson when dealing with anything JSON related.
On Windows, plugging in a new phone/tablet can be bothersome since you can need to install a new driver.
On OsX/Linux, it is pretty much transparent. take the phone, activate dev mode if it is not already the case, plug it and you are done.
I don't think that developing for Android is so complicated - but maybe you had some bad luck with a device.
But RELEASING your app is much easier on Android (the Play store) than on Apple's store.
We had developed some apps for some customers and it was always a chore to release them into the Apple app store.
Somebody paid us money to make an app for them and then we can't release it on IOS because you think it has no sense for people and that it was written with the wrong toolset.
It would be no problem if there was an easy way on IOS devices to use another, more open store.
Huhwhat? Download eclipse, search for "android" in the marketplace, click "ok" repeatedly, write your code, plug in your phone, push the deploy button, and it Just Works. At least that's always been my experience.
I have to second that. I'm a rather experienced java-developer, I've done two Android apps and the Android-SDK is one of the worst SDKs I've ever seen. Substandard doesn't even begin to describe it. No matter where you look it seems to throw in a Gotcha! with every step you're doing.
* The IDE-Integration is meh: I do like Eclipse, but even the SDK-Manager for Android bugs around. The Layouting-Screen is so slow that everybody edits the XML directly anyway.
This should get a bit better with Android Studio.
* The API seems to have been converted from a (bad) C-API. Loads and loads of useless inheritance. Whenever you instantiate an object in Android it brings along at least 15 methods that make no sense to call. It often doesn't even use generics. Happy casting. Why use enums when you can have Bitfields!
* Hardware acceleration is just a gamble. The doc here [0] says that you can enable it or disable it, except that sometimes that get's overridden and that you can enable and disable it partially as well, except that with some parts that doesn't work, especially in conditions that might apply sometimes.
In practise I've seen that enabling acceleration made some parts of my applications smoother, and some slower. This behaviour changes with every minor version update on the tablets, of course. Way to go Android!
* If you ask the Android API (on GalaxyTab 3) if an SD-Card ("external storage") is inserted, it will always return true, because the internal memory uses sd-card drivers and is always there.
That is one of these thousands of gotchas that cost you 30 minutes of debugging.
* Android's standard Activity has methods for storing and restoring state, which is reasonable except that those are not persistent and should be only used when the Activity get's destroyed and recreated during turning of the display, for example. If you want persistent state, so that your App can be killed, you have to invent it yourself. At this point, I did the turning-thing with my own mechanism as well, because it was less cumbersome and less code-duplication.
* MultiTouch is just messing around with raw values. There are 10 pinch-zoom libraries out there, and none of them is perfect.
I could rant on endlessly, so I will some it up:
* The android SDK is 50% crap, by which I mean that if you are doing something slighty complex than you will find yourself outgrowing the extremely limited usecases that it's Views allow you and reimplement new ones yourself. I even had to modify the TextView because it performs so badly.
* The android section of StackOverflow is the lowest-quality section I've seen there. Many questions are answered by workaround and hacks ("copy/paste this"), by, what seem to be programming-beginners. This is sad, because I assume that many people learn Java via Android, and the style it teaches or rather requires is plain awful.
Most in-depth questions are not answered at all, because no-one has a clue, I asked a couple of things regarding performance and the rendering-pipeline on the mailing-list, but never get answers other than "your app is slow? make it simpler and read our beginner's howto."
Most of the answers I got, I got by reading the sourcecode [1].
* Performance is terrible. Most of the performance it get's is gained by faster CPUs. Just think about this: In most animations android will need time in every frame to recalculate the height of each letter of whatever text is on the screen. Because most aren't cached. And you can't tell Android which things will change.
At some point I was even thinking about reimplementing a layout manager myself, because of stuff like this.
I've never had a problem with the Activity state, but then I always shove data in an SQLite database anyway, which isn't hard. Is it really that troublesome to implement?
No, but it get's on my nerves that Android always says "Hey I have something in my API for that", and I after a (short or longer) while I realize it doesn't work as expected.
I most often just use Json (because with Google Gson, you can just serialize it into an object without boilerplate).
Activity state is persisted to disk (by the ActivityManager). That's why your process can be killed to free memory then woken up again when the user task switches back to it.
Never had much of a problem with it; just use reflection to see if certain API calls are available (kind of like seeing if a function is available within a DLL/so natively, not a problem)
I found it easy to start, and the documentation is quite extensive and easy to follow.
This differs from my iOS experience, as xcode worked in a different way every new release, and the documentation on how to write things changed every time too, from what I could tell?
Back end developer. I tried producing the most basic of Android apps, to see how to get set up (displayed a message when a button was pressed). I didn't find it especially difficult. It was easier then setting up a lot of the server side stuff that I am used to. One file I had to edit form what I remember. Does it get a lot more difficult if I do something more complex?
It's all nice, but one major caveat: "from any OSX environment".
Many developers prever Linux or Windows and don't see a point in buying Mac just to develop for iOS.
Plug in an iPhone, and (after jumping through the byzantine code-signing system) you'll be able to deploy development code to it (from an OSX environment). If your app runs on one iPhone, it probably runs well on another, barring some screen geometry concerns.
Plug in an Android device, and you might need to search around to find a manufacturer-specific toolset, and/or navigate secret menus to enable debugging (like "click this menu item that doesn't look like a button seven times"). You might also have to worry about ancient devices that can't be updated to a modern Android version, and have egregious platform bugs. Comparatively, it's a mess.