Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com