Conspiracy theorists are out in force, saying that this is nothing more than a subtle ploy by Apple to make Web apps appear slower than their native counterparts, in an effort to keep developers tight in the evil grips of the App Store.
Apple has acknowledged the discrepancy, telling The Register, “The embedded web viewer does not take advantage of Safari’s web performance optimizations,” although the company has called some of the performance benchmarks “flawed”. But it is a squeeze play from Apple? Nobody can say for sure, but just as John Gruber pointed out on his Website, Daring Fireball, on Thursday, there are some valid technical reasons behind what is happening, which shed some fascinating light on how iOS works and the lengths to whichApple has gone to keep things safe and secure on the company’s mobile operation system.
How JavaScript works
At the core of the issue is a technology called Nitro. Initially dubbed Squirrelfish Extreme and announced in 2008, Nitro is the underlying engine that makes it possible for Web pages to run JavaScript code. This, in turn, is one of the ways in which a Web page can provide complex interactive features such as animations or application-like functionality.
JavaScript is an interpreted language, meaning that every time a Web page containing JavaScript code is loaded, the browser must evaluate the code and translate it into a series of actions that the computer can execute. In human terms, this would be analogous to having to re-take all your driver’s ed lessons every time you want to take the car for a ride because you forget how to drive the moment you step away from the steering wheel.
Clearly, this is a woefully inefficient way to run code. Among its many innovations, Nitro was designed to take advantage of a technique, known as just-in-time compilation, that efficiently translates JavaScript into binary code. While this doesn’t skip the compilation process, it results in code that is much more efficient than the step-by-step execution of the previous JavaScript implementations. Continuing our car analogy, using Nitro would be like having a neural device à la The Matrix implanted into your brain to instantly teach you everything you need to know in order to drive a car like a Formula-1 pro. In other words, with Nitro enabled, you browser “knows kung-fu.”
Data and code
This is where things get a little tricky for iOS. In order to preserve the integrity of mobile devices, the entire environment in which Apple’s mobile operating system works was designed so that only binary code that has been approved by Apple (by means of a digital cryptographic signature) can be executed.
Normally, this is not an issue, since all apps must go through the approval process, which gives Apple the opportunity to vet their reliability and security before they are released to the general public, as well as the ability to stop them from running should they ever be found to contain malicious code (the infamous “kill switch”).
Nitro, unfortunately, introduces a monkey wrench into this carefully orchestrated environment. When the just-in-time compiler kicks in, it converts JavaScript (which is plain text) into binary code in an area of memory that is marked for data usage; this would normally be used for things such as documents, graphics, or sounds, and is, therefore, not allowed to contain executable code.
In order to be able to execute the code it generates, Nitro needs to flip the memory in which the former is contained to code usage. On iOS, however, this requires special privileges that are normally denied to third-party apps for the simple reason that allowing their usage would negate the very basis upon which the operating system is predicated—it’d be a little bit like locking a prisoner away with the key to the cell. If the possibility of arbitrarily marking an area of memory as executable were open to any app, nothing would prevent a developer from downloading any code from the Internet and executing it, unbeknownst to either Apple or the end user.
Why Safari can and everybody else can’t
The reason why Safari is faster than Web views on third-party apps, therefore, is simply the fact that Apple trusts its own code not to violate any of the security tenets of iOS and so it is allowed an exception to the normal security policies. Nitro can execute the code it compiles, and that makes Web apps in the browser perform better.
What about Web apps that are added to the home screen? Well, it turns out that those apps don’t actually run inside Safari. Rather, they are executed inside yet another app, called Web. Obviously, this app has not been allowed to execute dynamic code, although the reason why this would be the case is not clear at this point.
Will Apple allow third-party apps to use Nitro?
Looking to the future, it’s likely that Apple will solve this problem by using a technique known as split processing, in which the browser’s rendering engine will be essentially kept into a completely separate execution space from the app that hosts it. This approach, which is part of the upcoming Webkit 2 engine that Apple is developing, ensures that the browser can be provided with the appropriate privileges without causing the latter to spill into the hosting application as well. When that happens, we should finally see Nitro and its speed-ups become available to all developers.
Of course, it’s entirely possible that Apple is at work on a completely different solution. As you can see, however, there is a perfectly logical explanation why things are the way they are—one that, incidentally, doesn’t need to ascribe any nefarious intention to the company. Regardless, I am sure that Apple’s penchant for secrecy will manage to keep the conspiracy theory enthusiasts busy for years to come.
iOS 4.3