All of this is great, and very informative, but it will make Mac software developers and critics -- guys like John Gruber -- laugh and laugh. The problem with

All of this is great, and very informative, but it will make Mac software developers and critics -- guys like John Gruber -- laugh and laugh. The problem with this analysis is that it embodies the Java Desktop Fallacy -- the idea that the primary problem with getting your application to work on every hardware platform is getting the code to compile and the libraries to load. Sun once thought like this. They built a cross-platform set of libraries and released them to the world. They were dutifully ported to every hardware platform. They still work. But Java desktop applications sank into the swamp and died, because the average Java application didn't act quite like a Mac app, or quite like a Windows app. It looked and acted like a crappy compromise, built by someone who was jack of all trades and master of none. The problem with getting your app to work with or without a multitouch screen, or a built-in accelerometer, or a hardware keyboard, is that an app designed for a multitouch screen is a completely different beast. Making the iPhone's photo album software work on a device without the iPhone screen would require a complete redesign of the app -- you don't have pinch-to-expand, you might not have the same smooth scrolling when the user waves their fingers across the screen. But maybe you can mitigate those missing features by designing some shortcuts for the handy hardware keyboard. But -- oops -- some phones don't have that keyboard, so now you need to design one app for multitouch, one app for single-touch but no keyboard, one app for single-touch with a keyboard... If you have the time and the budget you can just design eight separate apps for eight separate combinations of hardware and sell them all. And if you're lucky, and Android is that good, you might not need eight times as many coders to pull that off. But you might still need 8x the design budget, and/or 8x the QA budget. If you're not careful you'll need 8x the marketing budget. So there's an inevitable pressure to try the typical strategy: design one app, with one name, aimed at the lowest common denominator of hardware. Or design an app that runs great on the hardware used by one-eighth of the market, but looks kind of crappy to the other seven-eighths of the market. And the Windows Mobile folks have seen the result of that approach: At any moment, a team of Apple developers can come along and wipe the floor with your reputation.