[stevekinney]

My understanding is that only Safari gets access to Nitro (Nitro : Apple :: V8 : Google). Web Views inside native apps don't get access to Nitro. Even web apps that you save to your home screen don't get access to the faster rendering engine. This is apparently for security reasons. I think it's one of the biggest barriers to web apps being competitive on iOS. (The other is that there really isn't a good installation story.)

[mikemoka]

"security reasons" (= http://bit.ly/1d7p5Tq)

it would be interesting if they elaborate on those...

[wildpeaks]

More like "job security" reasons as they have less control over webapps than apps.

[streptomycin]

Same reason I think they're dragging their feet on various parts of HTML5 that everyone else has already implemented, such as IndexedDB.

[rimantas]

You forgot to mention the part where Apple was first to implement features that later become known as HTML5. Also, the story of Web SQL and IndexedDB is not so simple.

[streptomycin]

Can you tell the story that explains why Apple has done nothing with IndexedDB for years while every browser vendor implemented it a while ago? Because the story as I see it is very clear: Apple embraced the web when they had very small market share, and they're doing the opposite now that they have a good chunk of the market. Walled gardens generally aren't very profitable if you have only a tiny fraction of the market.

Of course, it'll be hard for you to tell a convincing story because (AFAIK) Apple hasn't even commented on IndexedDB. Strange, for such a well-established open standard. Even MS has supported it for years!

[robmcm]

My understanding was that Safari used JIT which is prone to security issues with how it executes that code.

As to why it's safer to do so in Safar that in a webview must be because the only API to safar is from the JS/HTML/CSS but with a webview you have a C/ObjectiveC API from the other side, which may be harder to protect against.

[EDIT] - More information on the topic from Gruber http://daringfireball.net/2011/03/nitro_ios_43 although there is no reason given as to why a UIWebView is more at risk from exploits than Safari.

[Alphasite_]

My understanding is that you would have to mark some of the apps pages as executable, iirc, which could allow for arbitrary code execution.

[jamiesonbecker]

That makes little to no sense.

This reeks of the same logic that caused them to disable HTML file upload buttons (there's "no" filesystem -- which is apparently why you can't even browse for photos and uploads until recent IOS).

This is what drove "there's an app for that" for so many years: Apple's systematic limiting of web apps into a severely curtailed walled garden so that the app store would -- in fact, could -- be the only source for real applications.

"Web Apps aren't as performant as native" is a direct result of such strategies.

In other words, those strategies WORKED. As with all anti-competitive practices, they will keep doing their job for a while, until something new and better (or at least workable) comes along.

[stevekinney]

What's extra fun is that when Steve Jobs introduced the iPhone in 2007, he explained that developers could write web apps if they wanted to create software for the iPhone.

[jamiesonbecker]

I remember that, excellent point.

[rimantas]

Ok, show me Android apps which are as performant as native. This nonsense about Apple fearing web apps should stop already.

[Touche]

They made poor initial design decisions which effectively put a speed limit on JavaScript apps. Currently they are not motivated to do the probably very difficult work it would take to fix the problem, that's why it's so important that the Chrome team gets its shit together and makes the speed of Chrome Android awesome (which, to their credit, is a goal for this year).

Unfortunately the lack of competition on mobile makes innovation very slow, there's no motivation to make rapid improvements.

[x1024]

It's really easy to "fix the problem". There have been fixes on Jailbroken devices for years.

[maxmcd]

I'm not going to make an assumptions about how hard it is for apple to solve the problem, but I'm sure people writing solutions for jailbroken devices have a much greater degree of flexibility when it comes to making changes to the OS.

[dirtyaura]

Nitro, to my knowledge, only optimises Javascript performance, but JS performance is not the only bottleneck. We noticed that DOM manipulation together with style and layout calculations play a big part, see http://blog.mikie.iki.fi/2014/02/some-numbers-on-mobile-safa...

It's very tough to make a quality app using HTML5 if you use gestures and animations. Coding it in native Cocoa/Objective-C is much easier at the moment than trying to polish that last 10-20% of your HTML5 app performance.