I work on a mac at home and like it quite a lot, I am also a big fan of windows 7, so I have no axe to grind on the "fan boy" front. I have been working on a mobile development project recently and thought I would share my findings and thoughts. We decide to build a W3C Widget HTML, CSS and JavaScript packaged up as a web app. Because the iphone and Android don't yet support these we are wrapping them with the awesome Phonegap. At present, we are resisting the urge to use Phonegap for anything other than wrapping.
When Apple first said they wouldn't be supporting Flash on their mobile products, I thought it was a brave move and a sensible one. I justified it on the grounds that a big part of the problem with early Windows systems was that it allowed developers to do whatever they wanted. Many of the reported crashes with which Windows became synonymous were due to bad software rather than the operating system. I am mainly concentrating on "flash has not performed well" section of Apple's argument and less so on the "we're making the web an open field of delights with puppies for everyone" (1 of many sources on Apples position).
Developing on the iphone has given me a further glimpse into where this position has taken Apple. It's been quite interesting to work on a project where I have had multiple mobiles to develop on side by side.
Mobile libraries
Initially, we went for jQuery Mobile, which at the time was still in alpha. I think it will be an excellent product when finished if you want to do rapid mobile development using jQuery and it's theme system. I am not a bit fan of having the structure of my HTML and CSS taken away from me, especially by something in such early stage of development. So we decided to hand roll a mobile library, which was relatively easy, quite performant and a great learning experience.
position: fixed
At first we only had an Android to test on, while we waited for the iphone and developer licence - oh and the mac we'd need if we wanted to develop for the iphone... The app we built had a header, main and footer section. We affixed the header and footer with position: fixed and all was well. The first time we tested with iphone, we realised why jQuery mobile was using a JavaScript solution. Because many web sites built for desktop use large header and footers, supporting position: fixed could cause lots of sites to display poorly on a mobile phone. Apple's position seems to be to remove support for position: fixed as a preventative measure. PPK explains and has suggested a solution however, web developers are left hacking in fixes. We decided to hijack the touch events and build our own scrolling mechanism - on the iphone css transforms for the scrolling give a much better effect than the usual manipulating the CSS top.
Video
I was disappointed by my android when I found that it refused to play my html 5 video in either ogv or webm format when in webview mode (i.e. as a web page installed as an app). The same video would play perfectly well when browsed to normally. The iphone on the other hand was lovely, it played the video flawlessly, if you don't mind it taking control of the playing of the video fullscreen. However, the video element ignores all touch and click events. This is because it requires them for it's own controls. In theory, removing the control attribute from the video element should allow you to attach events, however, in our web app, this has not yet been the case - investigation continues.
I am torn here in that I like using my mac and it's ease of use, stability and performance. I dislike the reduction of freedom involved with the iphone and ipad - which is why I have an Android. But then, I bemoan the performance of my Android... What tears the balance for me, is developing for Apple, where I can't use standard code because Apple has deliberately stopped support without providing an alternative. This seems counter-intuitive from their point of view as it forces developers to introduce hacks outside of Apple's quality control.