*sigh* I was really hoping that this thread would die but since it hasn't lets make sure this little debate gets the full truth treatment.
Lets look at the failings of Android:
1) Seven different screen resolutions.
This means apps have to make compromises on how they will display across each. This also requires that developer test across all seven versions to be sure their app will work properly. And to make matter worse, each phone maker has to provide the proper XML to screen position conversion routines. If they don't and use the stock Android code, several of the XML layout function calls fail to render the screen properly.
2) Three GPU configurations and one software only configuration.
That means apps have to detect which 2d/3d graphic features are available for rendering. Which has the net affect of producing poorly optimized code or extreme code bloat to account for these differences.
3) Four different memory configurations.
This is an OS issue at its core. Users can run out of memory simply because the phone maker decided to cut corners. And to make matters worse, some phone makers use very slow (IE cheaper to buy) SD memory interfaces. Which means even if you are lucky enough to be on Android 2.2.x or higher so that you can install Apps to external storage, the phone will be slower that *bleep* because the apps are constantly having to swap from SD to main memory.
4) Seven different main clock rates to the CPU.
Yeah, programmers NEVER know what kind of speed they will have available. Which is why a lot of game devs avoid Android like the plague.
5) Dalvik Virtual Machine.
95% of all applications written for Android are in Java. And since you have seen the first four points of all the possible combinations of hardware designs you now know the name of the software that allows these Java apps to run across them all. And anyone that knows anything about Virtual Machines will tell you that:
A) They waste memory.
B) They waste CPU time.
6) Multitasking Event Hooks.
This design for Android OS is some of the slickest code I have ever pulled apart. And it is also the most damaging to Android at the same exact time. To help explain this, I am going to give a real world example that is 100% verifiable.
EBay for Android upon installation hooks to several of the Event systems of Android. The one that seems the most harmless upon inspection is the one that does the most damage to battery life, CPU time and general discontent to the user.
EBay hooks to the "On change of connection". IE if you switch from WiFi to 3G or 3G to WiFi, the
EBay app has to reload into memory to handle the event. That's right folks. The app launches into memory whether you want it or not every time you leave the house or office and switch back to 3G. And here is the really COOL part. You don't even know it is happening. Because it happens in the background due to it being a multitasking OS and you gave it permission when you installed it. So if this app rolls into memory because of this event, that means an app you really wanted in memory probably just rolled out. And just imagine this,
EBay isn't the only app hooked to this event. So you could have a dozens apps that launch suddenly when you switch from WiFi to 3G. And people wonder why Android has such pathetic battery life if you don't ROOT it to turn this crap off.
7) Application Permissions.
Now here is a really interesting topic. Apple doesn't have this. Instead the user relies on Apple to review each application prior to the release on the market place. Some people call this "do it my way or the highway" censorship. So Google came up with App Permissions with NO review process. This requires the user to understand what a permission means and its implication. I know for a fact 90% of the users of Android don't have a clue what the full implications of a permission is. The most popular one used by developers is "Get current phone state". They claim they need it to do proper pausing of Applications when you get a phone call. BUT the entire permission also, AND THIS IS ONLY DOCUMENTED IN THE SOURCE CODE, allows the programmer to see the exact phone number and name attached to that incoming call. And if the app also has "internet access" that means the app can transmit that data without your knowledge back to the app creator. Oh yeah, privacy doesn't exist on Android. Recently ROM makers have implemented a new feature to help combat this. But you have to be rooted and understand how to even use the feature.
8) Currently 13 deployed versions of the API.
That means developers have to pick which API revision to compile against for the features they want versus the amount of people that will actually be able to run the application.
That should cover the biggest issues with Android.
Oh wait I forgot to mention one other fact about Android. It may have to drop Java integration or pay a huge licensing agreement soon based on a court case currently in progress. Should be interesting to see what Google decides to do. Motorola has decided to hedge its bet that Google is going to lose big time and has started developing its own OS. I can't wait to see what happens when Motorola finally decides to breaks away from Android.
BTW, I switched to iOS March 31st 2011 after missing two phone calls in one day due to the phone app being rolled out of memory because other applications being triggered by outside events in Android. I haven't missed a single call in iOS since switching. Sometimes "It just works" is the truth.