L'attenzione si è spostata da WebApps a Native quando è stato presentato l'App Store con il rilascio di iPhone 3G con iOS 2.0.1, presentato il 9 giugno 2008 al WWDC.
Inizialmente le applicazioni Web erano pensate per essere utilizzate con il primo iphone, ma il cambiamento principale si è verificato con il rilascio dell'iOS dedicato (o dell'iPhone come veniva chiamato allora) Software Development Kit annunciato all'evento iPhone Software Roadmap su 6 marzo 2008. L'SDK consente agli sviluppatori di creare applicazioni utilizzando Xcode che sarà eseguito nativamente su iPhone, iPod Touch e iPad. Anche prima di ciò, le applicazioni incluse erano state scritte in modo nativo, nonostante il fatto che una volta Steve Jobs avesse osservato:
The full Safari engine is inside of iPhone. And so, you can write amazing Web
2.0 and Ajax apps that look exactly and behave exactly
like apps on the iPhone. And these apps can integrate perfectly with
iPhone services. They can make a call, they can send an email, they
can look up a location on Google Maps.
And guess what? There’s no SDK that you need! You’ve got everything you need
if you know how to write apps using the most
modern web standards to write amazing apps for the iPhone today. So
developers, we think we’ve got a very sweet story for you. You can
begin building your iPhone apps today.
La differenza è semplice come quella differenza vecchiaia tra applicazioni "interpretate" e "compilate".
Le app native sono scritte usando linguaggi di livello inferiore (Objective C, C, C ++ usando l'ambiente di sviluppo Xcode) e sono compilati con API progettate per estrarre la massima velocità ed efficienza usando algoritmi e funzioni scritte specificamente contro l'hardware che sono destinato a essere eseguito. Compilare codice in codice macchina direttamente eseguibile è quasi sempre il metodo di esecuzione più veloce per un determinato compito software.
Le WebApp sono pezzi di codice generici non compilati che non sono in grado di utilizzare queste API e devono ricrearle o non utilizzarle. Sono scritti in linguaggi di livello inferiore come Javascript, Python o Perl e sono interpretati tramite un ambiente di runtime sul punto di esecuzione, il che consente una certa flessibilità a scapito della velocità grezza. La funzione di scorrimento è un esempio di dove l'app nativa ha accesso a routine altamente ottimizzate per consentire lo scorrimento superfluo, ma una webapp non lo fa perché non ha conoscenza o accesso alle API pertinenti. Molte web-app sono compilate al volo usando tecniche di compilazione 'just in time', ma mentre questo può ottenere alcuni miglioramenti di velocità, non può provvedere alla mancanza di una piattaforma API ottimizzata corretta in un linguaggio di livello superiore, quindi Javascript (che è l'unico runtime lato client supportato da iOS, anche se altri sistemi operativi, mobili e desktop possono avere accesso ad altri) che le app web di iOS sono scritte. Altri runtime sono disponibili per l'uso purché eseguano il lato server, fornendo un ulteriore risultato in termini di prestazioni
Nel caso specifico di Twitter, l'app di Twitter semplicemente non usa il webkit, sta usando altre routine scritte nell'obiettivo C che sono di nuovo (la parola chiave suppongo) ottimizzate per i migliori risultati in un modo in cui nulla in un browser può raggiungere. Stranamente, penso che l'app nativa di Facebook sia in realtà un involucro sottilmente velato attorno all'interfaccia utente di un webkit.