At Loopt we tried to do this. We made a hybrid app (Loopt Star), using web views for content and native code for tabs, Facebook Connect, modal dialogs, animations, etc. It didn't work. WebViews/Safari basically don't cache anything at all, and javascript performance is awful.
Out of desperation we even tried including a reverse proxy as part of the app to force meaningful image and css caching. Yes, the webviews were serving content from localhost, which was proxied transparently to our real servers and cached aggressively. Even that wasn't enough.
If you want your app to have a first class user experience, you have to go native. Maybe in the future things will improve, but right now users can tell.
I've been thinking about getting into iOS development but I'm on the fence about diving into learning objective-c. I'm a ruby/javascript guy primarily and I think I'd rather go the js route than objective-c, but I want to know what the limitations will be? Anyone have any insight they could share?
While it is not a pure HTML/JS app (it is a well-designed and engineered hybrid[1]), ivanzhao's Three Degrees shows that someone can ship a well designed app with web expertise.
One obvious limitation is you won't have Cocoa, or the frameworks built on top of it. Want to let the user take a picture using the iPhone's Camera? It only takes 2 lines of code, and it works exactly like the native app. Same goes for showing Google Maps (MapKit), editing contacts (AddressBook), and so on.
Since the book talks about accessing the geolocation facilities of the phone via JavaScript then that should clue you in to that as a kind of lower limit to the limitations. God that's garbled--- I think I mean to say if you can mess with GPS using just JavaScript then you shouldn't have much in the way of limitations. Can't be as good as objective-c and IOS, but this should be for lighter apps anyway.
WebKit has hooks for location services - any website can ask for access to the iPhone's location. It's things like accelerometers, gyros, and camera that are tougher.
It's also next to impossible to make a native feeling application. Scrolling, transitions, animations are all less fluid.
CSS3 transitions are virtually indistinguishable from native animations and transitions, when applicable (i.e. CSS3 obviously can't be used for some things, but is a 1:1 replacement for things like page transitions).
As for scrolling, a number of JS libraries/frameworks such as SproutCore now implement fake scrollviews using touch events and CSS transforms, transitions and animations. For example: http://touch.sproutcore.com/
As for the cameras, IIRC the Chrome team is proposing APIs for camera access to HTML5.
37Signals Chalk is the first that comes to mind. But we're doing a few of these apps where I work, and my HTML5 and CSS3 book shows how to do an offline app with the Web SQL storage API too. This is actually really cool stuff when you think about applications for business. You're not gonna write games with it, but you can make usable interfaces for your apps.
And if you feel the need to be on the app store, grab Titanium, use the Titanium.UI.webview control and point it at your mobile site. We're proably going to do that to make a few of our web apps show up on the stores, because we don't have the resources to develop native Android / IOS versions of the apps we are building. So we'll do Rails apps with HTML5 / CSS3 / JS and jQTouch or jQuery Mobile, and wrap them if people demand appstore access.
Apple have rejected apps in the past that do nothing more than point to a website. A common way to get around that is to implement a feature in native code, e.g. a banking app that points to the website, but has native mapping functionality for finding branches. I am not sure, but I think it's now covered under clause 12.3[1] of the guidelines[2].
1. Apps that are simply web clippings, content aggregators, or a collection of links, may be rejected.
You'd likely never even know that an HTML5 app wrapped in PhoneGap or Titanium wasn't native. There are many of those on the app store already. In fact, the subtitle of the book specifically mentions the app store: Making App Store Apps Without Objective-C or Cocoa.
Application that depends on the native browser of the iPhone, such as PhoneGap based application, has severe limitation imposed by Apple on how much memory they can take.
So far, I have downloaded several applications, mostly which I don't really need, to test the experience of PhoneGap based application. I should say, given the limitation, its quite impressive. However, if you are being really picky, its easy to notice if you have say, a list on the application, scrolling the list after the view is opened (even if its the second time), the scrolling isn't so smooth and stutter a bit.
Of course, for normal people (aka non-developers), they may not notice, much else know if it is a PhoneGap application or not.
Discounting games, the majority of the apps I've downloaded from the app store could be written with HTML5 and distributed as Titanium or PhoneGap wrapped apps. Some of them probably are and I'm just unaware of it.
For that matter, if I didn't remember I'd used "Add to Home Screen" to get the 37Signals Chalk app on my iPad's list of apps, I probably wouldn't realize it wasn't native.
I second your mention of Titanium. It's a cool JavaScript based SDK for writing mobile apps in general - easily ported to iOS, Android, Blackberry, and mobile web. http://www.appcelerator.com/
Using phonegap I created an app using Canvas & javascript called Tank! (knockoff of atari combat). It was super simple to do and banged it out in two weeks on the side while working full time. I probably spent less time developing it that it would take to actually learn objective c to start developing it using that language.
The biggest issue was framerate, which when tracking 4 fingers at the same time, it drops down to 6-8fps on the original iphone. Tracking touches is more cpu intensive than actually drawing the sprites. I capped the framerate at 8 fps and slowed down the tank movement so that this effect wasn't noticeable.
The major upside is that you can test and develop in the browser every change you make without compiling anything, then dump it into the framework and push it to the device. This really speeds up development.
Out of desperation we even tried including a reverse proxy as part of the app to force meaningful image and css caching. Yes, the webviews were serving content from localhost, which was proxied transparently to our real servers and cached aggressively. Even that wasn't enough.
If you want your app to have a first class user experience, you have to go native. Maybe in the future things will improve, but right now users can tell.