I developed a webapp (project management) before deciding to go native.
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.
"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
"I was wrong about Web apps being able to replace native apps right now"
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.
I own an iPhone but don't really follow the development side of things so maybe you could answer a question:
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.
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...
I disagree, I still think the first article was spot on. If you don't want to play by Apple's crappy App Store rules then write a web app for the iPhone. Unless you're doing a 3D game you can accomplish the same result on the Web and you're free from their 'control'.
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.
I couldn't disagree more. iPhone devs who write native apps are trying to get the best usability out of their products - have you played with an iPhone webapp recently? They approximate the native experience, poorly. The UI doesn't flow, it's not fast, it's not responsive - it's a pale shadow compared to a native app, even for mundane tasks like menus and buttons.
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.
Another important argument in favor of a native app over a webapp is the iPod Touch - sales of the Touch are doubling year over year, getting pretty close to the iPhone, in terms of units sold.
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.
That is a great point, although there are some things you can do with local caching it's not really a solution in that instance.
My main argument is, as a developer you KNOW what the App store approval process is like, it's been beaten to death all over the Internet. So either accept that you're going to have to play by Apple's rules or make a web app and save yourself the trouble. It's Apple's garden and we all just play in it.
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.