[RoyceFullerton]

I think the bigger problem is still iOS's webview from within native apps, not that it has to pull most of the assets from the server. If you go to m.facebook.com in Safari it is much faster than using the native application and most of it is the same HTML5 code that is running within the webview of the native app. The twitter app is also painfully slow when clicking a link and it opens up the resulting page in a webview.

[wonnage]

I've noticed this as well, and it seems to be a recent phenomenon - it's gotten to the point where I just open links in Safari when possible. Any idea why?

[RoyceFullerton]

One reason:

"...performance of UIWebViews is less than in mobile Safari. This has a lot to do with the absence of the new Nitro JavaScript engine in UIWebViews, apparently for security reasons. I ran some tests on my iPhone 4 with iOS 5.1.1, the JavaScript benchmark Sunspider running in Mobile Safari was 3 x as fast as running in a native app with a UIWebView. Also, to communicate from the UIWebView to the native app, a JavaScript bridge is needed. This is tricky stuff, slow and not really thread safe."

http://blog.mobtest.com/2012/05/heres-why-the-facebook-ios-a...

[raganwald]

This.

IIRC, the reason is that the Nitro engine compiles directly to native code, which is then executed. This requires writing to memory as data and then executing the data. However, Apple doesn’t allow third-party applications to execute data for any reason. This would violate security policies. Thus, any and all third-party scripting—be it JavaScript in a Webkit view or something else—must be interpreted. The best a third-party application can do is compile to byte codes and then interpret the byte codes.