⇥ The great UIWebView mystery

I am sure that we all have our pet peeves about whatever technology or platform we work with. In iOS, my biggest pet peeve is called UIWebView.

I happen to really like WebKit—Safari is my default browser when working in OS X, both for browsing the Web and for developing websites¹. I find the overall environment extremely powerful both for laying out interfaces and for performing all sorts of I/O operations.

I also happen to think that there is a lot to be gained by tightly integrating WebKit into iOS operations. For example, parsing XML files from JavaScript (particularly if you use a library like jQuery) is ridiculously easy compared to having to use NSXMLParser’s SAX-like interface, which looks like it time-traveled from the 1990s to annoy a whole new generation of programmers. Similarly, text layout is much more easily accomplished in HTML than using UiKit’s facilities—consider that FryPaper is built almost entirely in HTML and Javascript, with only a thin Objective-C shell around it to control navigation. Had I had to build it entirely in Obj-C, I would probably still be tearing my hair out or making compromises left and right.

Finally, let’s not forget the fact that WebKit is widely used across multiple platforms. This means that whatever you write in it is portable—you could build some of your interface for iOS and conceivably recycle it for an Android version of the same app, thus saving considerable amounts of development time and cost.

I hope that it comes as no surprise, then, that I am puzzled by the way Apple has set up UIWebView. It’s like they’re giving us a glimpse into this wonderful world of possibilities, where we can use the very same Web standards they are telling us are the future, only to keep the glass door firmly shut by crippling our access to the functionality provided by WebKit. We can’t poke into the DOM hierarchy without going through JavaScript—and our scripts aren’t allowed to raise any events inside their Obj-C container. We have no control over the scrolling—not even the same amount that we get from a UIScrollView.

To be sure, there are ways around this problem: typically, one creates fake URL requests that allow the Web content to notify the Obj-C code that something needs to happen, while ad-hoc JavaScript code can be used to issue command to the HTML side of things, and view masking can be used to control scrolling. But these workarounds introduce complexity (which breeds bugs) and make the overall use of HTML inside an app needlessly complex. Plus, it’s clear that they are not the way Apple intended UIWebView to be used, which means that they could yank the rug from under a developer’s feet with any new update.

The solution here has to come from Apple. UIWebView has gone essentially unchanged since iOS 2.0, and it’s time for an overhaul. Here are some random ideas:

• Give Obj-C access to the DOM model.
• Allow the registration of Obj-C methods inside the HTML document, thus making them securely callable from JavaScript.
• Allow the rendering engine to better interact with custom scrollable views
• Provide developers with an easy way to determine the WebKit capabilities supported by a given UIWebView renderer²
• Allow the developer to disable same-origin policy checking for a given document³
• Improve the ability to inject content into an existing document[.1 Currently, this can be done with a bit of clever JavaScript, but it's a horrible, horrible hack.]

I can only hope that someone from the UIKit team will eventually realize that UIWebView needs some love—particularly if Apple is really serious about making HTML and JavaScript serious contenders in the app space.