Apple gives you a boatload of really thoughtful, usable UI classes. What I've read is that Android's SDK UI code isn't nearly as substantial or mature. Can you confirm if this is the case?
edit: Then there's Core Data for object modeling and persistence, which is a huge time saver. Is there an Android analog of this with comparable power?
This results in shitty apps that are costly to develop. Fortunately, most of the apps that people actually use don't do this, so it's not really a big deal for users.
The API's have more gotchas and simple bugs than the Apple ones.
The 1.6 API in particular has some hairy bugs.
The debug cycle takes considerably longer (almost 3x as long as the iPhone debug cycle for a non-media app).
The debugger doesn't work as well.
The lack of a GUI UI layout tool (there are some, they don't work well yet).
The project setup is considerably more time intensive (barring signing issues, which experienced iPhone shops don't have issues with really).
Now it's not all against android: The lax approval criteria and ease of market publications are awesome. I'm just saying it costs MORE to do android, I'm not saying don't do it.
And yes, you're right, custom widgets are harder in android than in iOS. If it makes you feel better, I find the amount people change iOS custom widgets silly too.
On the NS prefix: Lots of fun to switch between iOS and OS X dev. Wrote my first OS X app a couple months ago and it was weird to stop using the UI prefix for all the view classes.
My big wish for the next major iOS SDK is to get bindings. Those are awesome on the desktop.
I wouldn't expect this. Honestly I'd expect things to go the other way: 10.7 maybe deprecating bindings on the Desktop for things like table and outline views. Particularly since they added NSTableViewDataSource/Delegate and NSOutlineViewDataSource/Delgate in 10.6.
For collections, though, I feel like they're more likely to get you into trouble than to actually solve your problems.
I think you could do something substantially less complicated/powerful than bindings for the cases that bindings handle well, though, and I'd rather Apple did some innovating there than bring bindings over to iOS.
I'm also with the other folk who would much prefer to see Garbage Collection first. I rarely get into trouble with the reference counting system, but when I do it usually takes me forever to track down why my app is crashing without a single line of code written by me in the stack trace. Usually it's because I assigned an autoreleased value to an ivar in an init method while failing to retain it (a stupid mistake that I still make once every few months even after 5 years of Cocoa/Cocoa Touch work).
I want GC on the iPhone. Not for the GC itself, just so Apple will make NSPointerArray, NSHashTable and NSMapTable part of the public API.
Will be astonished if they get deprecated on desktop, too. Value is far too high.
Lack of GC seems to be an artificial constraint designed to force dev's to take charge of a situation with very limited memory. Unless there was some major overhaul to the Foundation classes.
Am I way off?
The real skill is in explaining why this is difficult and actually how much design work needs to be undertaken to make these "simple, clean" looking apps
However it has to be said there are some quick wins for mobile apps that can be achieved quickly, however something like twitterific which is probably one of the top 2% of iPhone applications the effort expended is not that surprising unfortunately