First, I would like to see an example of a rich iPhone webapp he has created (if any) to show off exactly how "native-like" it actually feels to use...<p>As for me, I have written an iPhone webapp which is located at <a href="http://tweetgrid.com/iphone/" rel="nofollow">http://tweetgrid.com/iphone/</a> (it is a twitter search app). I used the <a href="http://iwebkit.net/" rel="nofollow">http://iwebkit.net/</a> framework (which is brilliant), but overall it was an exercise in frustration.<p>A few points:<p>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 <i>also gets cached</i> even if that page is <i>not specified</i> 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.<p>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.<p>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.<p>I didn't even deal with the payment stuff with my webapp because I made it free, but that would be a huge pain.<p>Conclusion: I am learning Objective-C with reckless abandon.