As for me, I have written an iPhone webapp which is located at http://tweetgrid.com/iphone/ (it is a twitter search app). I used the http://iwebkit.net/ framework (which is brilliant), but overall it was an exercise in frustration.
A few points:
1. You can create a webapp that will launch as an independent "app" if you save the page to your homescreen (i.e. it loads in a one-tab Safari "full-screen" mode, so no Safari navigation bars are displayed). As such, I built in some smarts that will actually detect whether the site is loaded from "normal" Safari or "app" Safari. If it loads in "normal" mode it shows some instructions about how to install the app on your home screen. If it loads from "app" mode those instructions are gone. I also use this mechanism to determine how many times the app has been "installed" onto phones. This is done server-side because I need to see the user-agent to determine this. This is where I ran into a huge issue with the Safari caching mechanism. I am not sure if it is part of the HTML caching spec, or something specific to Safari's implementation, but which ever page you use to specify the cache manifest file also gets cached even if that page is not specified in the manifest. This is idiotic. The only logical place to put the manifest reference is in the "home" page where the app loads. This means that any updates to the page won't be seen for a long long time (if ever). This also subverts my normal-mode/app-mode logic because the home page doesn't ping the server when it loads. Ultimately I had to do away with most of the caching in order to regain the other functionality. This means that everything loads very slowly compared to a native app.
2. The average user doesn't understand "webapp." When somebody hears "app" and "iPhone" they immediately go search for it on the AppStore app. There is no realm of understanding about webapps. Finding (and installing) webapps is hard. "Open Safari, type in this URL, click the plus sign to create a bookmark or add it to your homepage..." is orders of magnitude harder for Joe Public than "search for XYZ app, and click Install." You don't even need to say "open the AppStore" because that's already implied. I would get complaints from users saying, "I can't find TweetGrid in the app store!!!" Then I had to politely tell them that, "No, it's not a native app, you need to load it in Safari and save it to your home screen..." which just caused more confusion.
3. PPK speaks of interoperability of webapps, but he also talks about using iPhone specific javascript APIs to access hardware on the iPhone... once you head down this path, you can't really call it interoperable anymore, imho.
I didn't even deal with the payment stuff with my webapp because I made it free, but that would be a huge pain.
Conclusion: I am learning Objective-C with reckless abandon.
"Apple has spent time and effort making native apps work seamlessly, they haven't bothered for web apps"
This applies to missing APIs for photo upload, bugs or missing features in Webkit (even stuff that's there but not widely known), user "installation", even payment.
If that is the case then you can say "webapps are limited (currently (on the iPhone (compared with native Cocoa apps)))" but that's a completely different statement from "webapps suck".
What's odd is that Google isn't banging this drum hard for Android, but they are for ChromeOS.
Some of the additional reasons why I believe users prefer native apps are:
1. The app store app and iTunes make it easy to discover native apps. Webapps are simply posted on a link from apple. This makes it harder for users to discover them. Here is the link to webapps: http://www.apple.com/webapps/
2. With native apps, users can take advantage of built in UI elements reducing the learning curve and creating richer applications.
3. Web apps can suffer from performance issues especially when you are on an edge network.
4. Payment processing was already mentioned. Its an issue but probably not a huge one.
I think the native look and feel and Apple's own promotion are the two big factors in favor of native apps.
Strange, as I'm fairly certain he didn't say that.
He said the lower end could be replaced with web apps right now and if Apple opened up more API's to web apps then many more apps could too. Which is true.
Also, Apple's "App Store" for Web Apps:
http://www.youtube.com/watch?v=SAWDYaWAVQQ
"Whatever position I took originally, I would change the position to exactly the opposite and tell the Macintosh people that I was completely wrong and they were completely right all along, and the numbers would go through the ceiling!" -John Dvorak
A short while ago all the iPhone devs were complaining that their apps were being overshadowed by total crap that was being churned out and sold at 99c.
Did that get fixed? Because that seems to be the downside of the easy charging of consumers, yet no-one has mentioned it during this recent storm in a teacup.
iPhone devs who write native apps and then complain to Apple about the app store policies are stupid, because they are tilting at windmills when there is a much easier solution to the problem.
There's "good enough" and "excellent" - these are not the same thing. It seems like the webapp apologists are in the "good enough" camp, and they're certainly right: Apple's webapp facilities are good enough.
But they're not great, and great UI is the defining feature of the iPhone. If you lose it all you have is a piece of plastic that has fewer features than the competition. IMHO also, the constant settling for "good enough" UI is a hallmark of programmer-driven UI, which rarely results in usable apps by regular people.
Requiring iPod Touch owners to connect to wifi before they access your webapp just puts another hurdle between you and your users, one which they won't always be able to clear.
