

Ask HN: Why is UIWebView in iPhone SDK a second class citizen? - th0ma5

I tried my hand at development for the iPhone the year before last, but all of ideas blurred the line between native and web applications. However, this proved to be impossible on the iPhone as the UIWebView isn't even close to being Safari. Now I hear the new OS upgrade doesn't offer access to the new optimized JavaScript engine. I know Apple wants to control various aspects for overall better user experience, but it seems that the only options are to fork WebKit or otherwise be someone with the money to be able to negotiate with Apple. Does anyone know of practical, exact reasons why this may be, or is Apple really trying to weed out the lone developer with ideas that are alternatives to the Apple way?
======
nerd_in_rage
what were you trying to do? I've found the UIWebView to be pretty decent and
have worked on some hybrid native/web apps.

I have native code calling into JS code that runs in UIWebView, and JS code
calling back into Obj-C, etc.

~~~
th0ma5
Oh don't get me wrong, it does I guess what it promises, but lets take for
example scrolling. The built in Safari has great physics reactions and overall
nice and speedy. The UIWebView is very flakey on scrolling (this was I guess
version 3 something when I was messing with it). In general, the rendering I
found to be rather different at subtle CSS settings. The same page in Safari
would act one way, whereas UIWebView would render it differently. Now lets
talk same origin policy. Android and iPhone both honor this as they should,
but at the time I was developing, iPhone even enacted this for XML calls. If
you did an XML call on the Obj-C side, from a remote server, it would not let
you mix that data with your local served web page resources. Now the biggest
thing is this point some of dev friends are making that there's a new
performant javascript interpreter, but it is hands off to the developer.
Another avenue I tried was to access iframes, from a foreign server, with
javascript, ala greasemonkey ... no go there. The origin policy is enforced
because the page running your javascript is locally hosted. I love the origin
policy for general web use, but if I'm designing a browser more or less, it
shouldn't apply. I would also think this is safe because UIWebView seems to
support having its own history, cookies, etc, so it isn't like I'm trying to
sniff what else the user might be doing elsewhere. So far in my android dev
experience this all just works, and I'm even given a WebKit class to work
with.

