How come web apps don't run as efficiently as native apps on the iPhone?

Solution 1:

The focus shifted from WebApps to Native when the App Store was unveiled with the release of the iPhone 3G with iOS 2.0.1, which was introduced on June 9, 2008 at the WWDC.

Initially Web Apps were intended to be used with the first iphone, but the major shift took place with the release of the dedicated iOS (or iPhone OS as it was called then) Software Development Kit announced at the iPhone Software Roadmap event on March 6, 2008. The SDK allows developers to create applications using Xcode that will natively run on the iPhone, iPod Touch and iPad. Even prior to that, the included applications were written natively despite the fact that Steve Jobs once remarked:

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.

The difference is as simple as that age old difference between "interpreted" and "compiled" applications.

Native apps are written using lower level languages (Objective C, C, C++ using Xcode development environment) and are compiled against APIs that are designed to extract maximum speed and efficiency using algorithms and functions that are written specifically against the hardware they are intended to be run on. Compiling code into directly executable machine code almost always the fastest method of execution for a given software task.

WebApps are generic uncompiled pieces of code that are not able to make use of these APIs and have to either recreate them or not use them. They are written in lower level languages such as Javascript, Python, or Perl and they are interpreted via a runtime environment at the point of execution, which allows for a certain flexibility at the expense of raw speed. The scrolling function is one example of where the native app has access to highly optimised routines to allow super slick scrolling, but a webapp doesn't because it has no knowledge of or access to the relevant APIs. Many web-apps are compiled on the fly using 'just in time' compilation techniques, but whilst this can gain some speed improvements it cannot cater for the lack of a proper optimised API platform at a higher level language then Javascript (which is the only client side runtime that iOS actually supports, although other OS, mobile and desktop may have access to others) that iOS webapps are written in. Other runtimes are available for use so long as they perform server side, which provides a further performance hit.

In the specific case of Twitter, the twitter app is simply not using webkit, it's using other routines written in objective C which are again (the key word I suppose) optimised for the best results in a way nothing in a browser can achieve. Oddly, I think the Facebook native app is actually a thinly veiled wrapper around a webkit UI.