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...
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.
Isn't this (and many other similar points) just a generalisation of:
"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.
Thanks for the info! One question: would it be possible to release a web app as a "normal" app, too? Like submit the "app Safari" version to the app store or something like that?
I suppose you could wrap everything in a WebKitView (or whatever it is called) and just submit that to the AppStore, but as some have pointed out before, you will probably get a "Mature" rating because all data is loaded from the web...
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.