[Ed Zachary]

Having spent a few years developing applications, including mobile apps, I can tell you there are a lot of things involved. First, each manufacturer has its own version of the OS. True, you have the MAC OS/iPhone hardware organization under the same umbrella. But, under the covers, WM6.1 varies a bit from manufacturer to manufacturer based on hardware constraints.
Then you have the API, or Application Programming Interface, that is (or is NOT) available to developers and the capabilities that are freely available to developers through those APIs. For instance, MikeySoft has a WMF API that any developer can use to build apps for WM devices. This is a one-size-fits-all approach. Or, more realistically, an all-better-fit-this-size approach. Can you say "common denominator"? Some hardware vendors will make APIs available that can be used with WMF, but those usually make it easier to deal with specific hardware, not enhance the "user experience".
One client I worked with developed a pretty slick library of classes that included things like 3D buttons with graphics and animations, non-stock colors, and extensively subcl***** controls. The apps we created were, and still are, gorgeous and highly intuitive. BUT it took a lot of time (and money!) to build that library.

Which brings up the main reason for lightweight-looking and acting mobile apps: time to market trumps all. Apps have to be created as quickly and cheaply as possible in order to get them out the door and realize a return on the investment of time and money. This in and of itself pretty much rules out building libraries of robust and extensively reusable classes. Or making those classes easily portable to multiple platforms. Or porting apps with much complexity at all to multiple platforms. Or thoroughly testing all combinations and scenarios of interactions and data and platforms.


Edit: Ha! Smutcheck won't let ess-you-bee-cee-el-ay-ess-ess-ee-dee through...