Apple admits to slower performance in iOS web apps [Updated]

You might remember a few days ago that we reported slower performance from web-based applications in iOS as opposed to those launched directly from Mobile Safari. Now, Apple has confirmed the problem.

In a statement to The Register, Apple has stated that “the embedded web viewer does not take advantage of Safari’s web performance optimizations.” As a result, any application that is not launched from within Safari will not take advantage of Apple’s Nitro JavaScript engine.

The newest information that we have came from earlier today. Blaze Software has produced a set of tests which show the speed differences between Android’s and iOS browser loading in depth. While in most cases, the differences of a page’s load time will be less than 1 second, it is still significant as to the end result affecting the rest of the applications. It’s worth mentioning, though, that in Blaze’s test case it was an external browser launch that performed the test, which would fall under the issue Apple is now addressing.

What’s interesting is that, even though Apple has stated a full support for Web applications, including HTML5, these most recent findings do not appear to provide an equal ground for testing. As a result of Apple’s work, applications that are not launched from within Mobile Safari will perform slower, thereby appearing to be of lower quality than a “native” app.

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

The question that remains is whether this is an oversight on the part of Apple, or whether it is quietly intentional. With the company’s stand against Flash, an open standard of HTML5 should be its next logical thing to support. But if it doesn’t fix the problem in future versions of iOS, that leads a hefty credence to the rumor mill.

Update: Over at Daring Fireball, we get a more in-depth explanation of a reason why things could be set up as they are at present:

The real answer is about security. Perhaps the biggest reason for Nitro’s performance improvements over WebKit’s previous JavaScript engine is the use of a JIT — “Just-In-Time” compilation… A JIT requires the ability to mark memory pages in RAM as executable, but, iOS, as a security measure, does not allow pages in memory to be marked as executable. This is a significant and serious security policy. Most modern operating systems do allow pages in memory to be marked as executable — including Mac OS X, Windows, and (I believe) Android1. iOS 4.3 makes an exception to this policy, but the exception is specifically limited to Mobile Safari.