differences between uiwebview and mobile safari [closed]

Answer 1

When it comes to performance this is the best summary you are likely to find: http://www.guypo.com/mobile/ios-browsers-speed-bakeoff/

Answer 2

It doesn't have the Nitro Javascript engine. This makes executing Javascript much slower in UIWebView compared to Safari.

http://www.tuaw.com/2011/03/18/apple-confirms-some-webkit-optimizations-unavailable-to-ios-apps/

http://ariya.ofilabs.com/2012/06/nitro-javascriptcore-and-jit.html

Answer 3

When UIWebView scrolls its content, it freeze all JavaScript events until the end of scroll. So you absolutely can not programmatically observe and/or control the scrolling process like this common way:

window.onscroll = function() {
    var scrolled = window.pageYOffset || document.documentElement.scrollTop;
    // do something
}

because variable 'scrolled' will be updated only once - after the scroll is completely finished.

Answer 4

One thing I found, to my temporary sorrow is that UIWebView is a bit more strict while setting style values through JS. So say in mobile safari

element.style.width = 300; 

will work just fine, but in UIWebView you must set the value as

element.style.width = 300 + "px";

There are other differences which I'm discovering slowly. I'll update this as I do.

Answer 5

Two obvious ones I have come across are authentication and pages with frames.

For authentication, UIWebView does not handle authentication challenges automatically, it's up to the developers to handle them.

For pages with framesets, UIWebView does not keep track of the browsing history for page transitinos within frames, which may be a desirable feature. It needs a bit of fiddling to accomplish this.

Answer 6

You can set the initial max size for HTML5 SQL in Mobile Safari to 50MB, but UIWebView seems to be limited to 5MB. It refuses anything higher.