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.