I'm of the view that in general, it's better to code directly to the iOS APIs rather than trying to implement everything in a UIWebView. Having said that, I've

I'm of the view that in general, it's better to code directly to the iOS APIs rather than trying to implement everything in a UIWebView. Having said that, I've just spent a substantial amount of time developing a word processing application (UX Write), which uses a UIWebView for all document layout, and a large amount of "backend" code in javascript for performing editing operations. All the UI code however is written in Objective C and the Cocoa Touch APIs. The advantage of using native controls it it provides a much greater integration with the rest of the operating system, and makes it easier to make your app work in the same manner as other apps. For example, there are many features of iOS that are not exposed through javascript APIs, and for that you have no option but to use native code. Nonetheless, I like what Microsoft is doing with providing javascript APIs for metro development, and though I haven't tried it myself, it looks like a good approach. There are a number of serious problems with the current UIWebView which are also holding it back as development tool: - You have very limited control over touch events. In my case, I completely disabled all default event handling on the web view, and implemented my own touch event handlers in Objective C, which pass the events through to javascript. - Selection is broken. You can access the selection, but not modify it. I spent several weeks completely reimplementing the selection & cursor mechanism because of this. One positive outcome though was it gives me much more fine-grained control over user interaction issues. - contentEditable is also broken. I spent probably 3-4 months reimplementing this functionality myself in javascript to make it usable - Interfacing between Objective C and Javascript is tricky. Going from ObjC -> JS is fast, but going in the other direction using the technique from the article is painfully slow. There a ways to work around this but it's inelegant and doesn't allow return values from callback functions. - Lack of Nitro support, as discussed elsewhere. It turns out that for my particular needs performance is quite acceptable, but for more compute-intensive apps like games it's a must. I can understand Apple's desire to prevent W+X permission on memory, but this could be solved by running JS code in a separate process and communicating with the host process via shared memory. Apple have done some amazing things with WebKit, but the iOS port leaves a lot to be desired. I would really like to see them improve these apps so people can better integrate web content & backend functionality. But I still think you should be using Cocoa Touch for your UI.