L'accent a été mis sur les applications natives plutôt que sur les applications Web lorsque l'App Store a été dévoilé à l'occasion de la sortie de l'iPhone 3G avec iOS 2.0.1, qui a été présenté le 9 juin 2008 lors de la conférence WWDC.
Au départ, les applications Web étaient destinées à être utilisées avec le premier iPhone, mais le changement majeur a eu lieu avec la sortie du kit de développement logiciel dédié à iOS (ou iPhone OS, comme on l'appelait à l'époque), annoncé lors de l'événement iPhone Software Roadmap le 6 mars 2008. Le SDK permet aux développeurs de créer des applications à l'aide de Xcode qui fonctionneront nativement sur l'iPhone, l'iPod Touch et l'iPad. Même avant cela, les applications incluses étaient écrites en mode natif, en dépit du fait que Steve Jobs ait fait remarquer un jour :
Le moteur Safari est entièrement intégré à l'iPhone. Vous pouvez donc créer des applications Web 2.0 et Ajax qui ressemblent exactement et se comportent exactement comme des applications sur l'iPhone. Et ces applications peuvent s'intégrer parfaitement aux services de l'iPhone. Elles peuvent passer un appel, envoyer un courrier électronique, etc. envoyer un courrier électronique, rechercher un lieu sur Google Maps.
Et devinez quoi ? Vous n'avez pas besoin de SDK ! Vous avez tout ce qu'il vous faut si vous savez comment écrire des applications en utilisant les normes web les plus standards web les plus modernes pour écrire des applications étonnantes pour l'iPhone aujourd'hui. Ainsi, pour les développeurs, nous pensons avoir une très belle histoire à vous raconter. Vous pouvez commencer à créer vos applications iPhone dès aujourd'hui.
La différence est aussi simple que la vieille différence entre les applications "interprétées" et "compilées".
Les applications natives sont écrites à l'aide de langages de niveau inférieur (Objective C, C, C++ avec l'environnement de développement Xcode) et sont compilées avec des API conçues pour extraire une vitesse et une efficacité maximales à l'aide d'algorithmes et de fonctions écrits spécifiquement pour le matériel sur lequel elles sont destinées à être exécutées. La compilation du code en code machine directement exécutable est presque toujours la méthode d'exécution la plus rapide pour une tâche logicielle donnée.
Les webapps sont des morceaux de code génériques non compilés qui ne sont pas en mesure d'utiliser ces API et doivent soit les recréer, soit ne pas les utiliser. Elles sont écrites dans des langages de niveau inférieur tels que Javascript, Python ou Perl et sont interprétées via un environnement d'exécution au point d'exécution, ce qui permet une certaine flexibilité au détriment de la vitesse brute. La fonction de défilement est un exemple où l'application native a accès à des routines hautement optimisées pour permettre un défilement très fluide, ce qui n'est pas le cas d'une application web, qui n'a pas connaissance des API correspondantes ou n'y a pas accès. De nombreuses applications web sont compilées à la volée à l'aide de techniques de compilation "juste à temps", mais si cela permet d'améliorer la vitesse, cela ne peut pas compenser l'absence d'une plate-forme d'API optimisée appropriée dans un langage de niveau supérieur à Javascript (qui est le seul moteur d'exécution côté client qu'iOS prend en charge, bien que d'autres systèmes d'exploitation, mobiles et de bureau, puissent avoir accès à d'autres) dans lequel les applications web d'iOS sont écrites. D'autres moteurs d'exécution peuvent être utilisés à condition qu'ils fonctionnent côté serveur, ce qui entraîne une baisse supplémentaire des performances.
Dans le cas spécifique de Twitter, l'application twitter n'utilise tout simplement pas webkit, elle utilise d'autres routines écrites en Objective C qui sont encore une fois (le mot clé je suppose) optimisées pour obtenir les meilleurs résultats d'une manière que rien dans un navigateur ne peut atteindre. Curieusement, je pense que l'application native de Facebook est est en fait une enveloppe à peine voilée autour d'une interface utilisateur webkit.
