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.
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”).
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.