Peu de temps après une étude menée par Blaze Software affirmait haut et fort qu'un Nexus S était en moyenne 52 % plus rapide qu'un iPhone 4 pour surfer sur le web. Or, cette étude n'a pas été menée directement via Safari, mais dans une WebView.
Ces différentes informations n'ont pas manqué de créer une petite polémique, qui une fois n'est pas coutume, a poussé Apple à sortir du silence. L'un de ses porte-parole, Trudy Miller, a confirmé que les vues web ne comprenaient pas toutes les optimisations de Safari. Par conséquent, l'étude de Blaze Software est en partie inexacte. Il est faux de dire que le navigateur de l'iPhone est plus lent que celui d'Android. Par contre, l'exécution de web app (sans passer donc par le navigateur) est effectivement nettement plus rapide sur Android.
Alors pourquoi les web apps sont-elles privées de Nitro et de l'absence de prise en charge du cache HTML5 ? Pour John Gruber, il ne faut pas voir le mal partout et imaginer que de la sorte la société californienne privilégie les applications natives aux applications web.
Le vrai problème pour Apple, c'est la sécurité. Contrairement à ses prédécesseurs, Nitro est un moteur JavaScript qui inclut la compilation à la volée (JIT). Or, une JT nécessite d'avoir la capacité de marquer des pages mémoire en RAM comme étant exécutables. Or, contrairement à Mac OS X, Apple l'interdit sur iOS pour des raisons de sécurité. Un tel mécanisme détourné pourrait aboutir à de l'exécution de code non signé.
Autrement dit, si Safari sous iOS 4.3 est nettement plus rapide, il y a une contre-partie non négligeable : si quelqu'un parvient à exploiter une vulnérabilité de son navigateur, alors elle peut faire bien plus de dégâts que par le passé. On imagine qu'Apple a suffisamment confiance dans son navigateur pour intégrer une telle possibilité.
Pour Gruber, il est plus que probable qu'Apple ne va pas en rester là. Il estime que pour généraliser Nitro aux applications web, il faudrait qu'une application web puisse exécuter JavaScript dans un processus séparé et indépendant, un peu à l'image de Safari sur Mac et PC qui crée un processus séparé pour Flash. En théorie, c'est ce qu'Apple prépare pour Webkit 2, dont le projet avait été annoncé en avril dernier : "WebKit2 est conçu à la base pour supporter les processus séparés, où le contenu Web (JavaScript, HTML, etc.) fait sa vie dans un processus séparé […] ce modèle est similaire à celui de Google Chrome, à la différence majeure que nous l'avons construit directement dans le framework, et qu'il est accessible aux autres navigateurs".