Most likely he means that Android developers don't need to deal with their apps being 2nd class citizens the way iPhone developers do. Unless you work for Apple:

1) You are restricted as to which parts of the SDK you can use.

2) Your app may be rejected for any reason, no reason, or whatever reason. The reason may or may not be explained, and may or may not make sense.

3) Even if it isn't rejected, it will still take weeks or months to get your app into the hands of customers.

None of this applies to Apple apps, of course. Therefore, independent developers are 2nd class citizens of the iPhone.

Gotcha. I'd misinterpreted the remark. Thanks!

What he means by all apps being first class is that it's really a dogfooded API and platform. Apple is pretty far from the "we build our own apps in the same sandbox you do" state that Android is in.

As an example: Twidroid (and most other Android apps) can run in the background, and use data in the background without a custom push server. Apple's Mail app, on the other hand, isn't buildable (for the iPhone) with the public APIs. You'd need to run in the background for that, which isn't available.

Don't judge the API based on the quality of apps you're seeing - I've seen some well-polished Android apps, and some legendarily horrible iPhone ones.

first class means that there is no priority in which apps can do what. Apps can be written for Android that completely replace core functionality, like the dialer or the contact list, or even the home screen. With the iPhone, there are multiple classes of apps, and anything not sanctioned by Apple takes a backseat to those apps provided or sanctioned by Apple. This is evidenced by the "duplicates functionality" limitation of the Apple vetted App store.

Have you seen some of the upcoming Android phones? As much as I hate Verizon, the Verizon Droid from Motorola looks like it'll be every bit as good hardware-wise as the current gen iPhones.

See here for a comparison of the Droid and the iPhone 3GS (http://www.networkworld.com/news/2009/101909-droid-vs-iphone...)

Which is great and all, but the fact that you only need to develop for (effectively) one piece of hardware is still a huge competitive advantage for the iPhone vs. anything else. (Except the Pre, but the Pre has other problems.)

If you look at the way the Android SDK handles device differences, it's really much less of an issue that most people seem to make it out to be. Accommodating different resolutions, for example, is pretty trivial for an Android app developer. The only (IMHO) that might be an issue is the differences in input capabilities (ie, hardware keyboard or no hardware keyboard, trackball or no trackball, etc). That should no be an issue at all for productivity apps, but I do see how it could be an issue for games. It's hard to balance your level difficulties and design your play mechanics if you're not sure what kind of input device your players will be using.