Web or Native?

credits: http://monolithinteractive.com/2011/02/04/web-or-native/

For mobile developers, whether to build a native or web application is an important decision. The choice must be made wisely as it impacts the user’s entire application experience. Until recently, the decision was usually clear-cut: native apps are faster, better looking, and can use more device features, web apps are simpler and can run on multiple platforms. But web apps are closing the gap in the look and feel, speed, and even access to device hardware features, like GPS data. Even so, there are still some cases when a native app is the way to go.


A native application runs on the operating system for which it was developed. On the iPhone, native applications are written in Objective C and run on iOS, Apple’s mobile operating system. This means that the app, and any updates, must be installed by the user via Apple’s App Store distribution and approval process. Native applications have the advantage of access to hardware features, such as the camera, accelerometer, and compass. In addition, software development kit (SDK) frameworks give developers access to iPhone resources, including contacts, calendar events, and photos. Native applications also allow the developers to design richer user experiences.

The pitfall to native applications is that they are single platform. Such applications are designed with a single platform in mind and are not easily portable to other platforms. It can be nearly as much work to port an iPhone app to run on an Android device as it was to develop the iPhone app.
For a variety of circumstances, developing a native application is the best choice. For instance, if the application is complex in that it contains many screens or steps, such as a game or complex animation, building a native application would be wise. Native apps are also best when lots of data must be stored on the phone or when speed is a priority. Applications which require use of most hardware features, for example knowing how the device is tilted, must use native apps as such information cannot be attained through a web application.


Web applications, of course, run on web browsers. They are written in HTML+CSS and JavaScript. Web apps fill certain needs of developers that native applications cannot. One of the biggest benefits of web applications is that they are multi-platform. These apps can run on iOS as well as Android, Symbian, etc. JavaScript, however, may not be interpreted in the same manner by some browsers and in some cases, may not be interpreted at all. In these situations, porting efforts may be required. Another benefit of web apps is that they do not require installation. Any user interaction with Apple’s App Store is unnecessary, although, the option of packaging the application for distribution by the App Store is available.
If you considered a web app even 6 months ago, take another look at what can be achieved. New frameworks have made web app an option for apps that would have needed to be native not long ago.


There are new web app features, mostly from HTML5, that aren’t commonly known:

  • Web apps can be cached on the iPhone for offline use when a wifi or 3G connection is not available.
  • They can also store local data, even a client-side database on the mobile device.
  • Hardware access is slowly being opened up. On the iPhone, web apps can get the user’s current location from the GPS.
  • New Javascript frameworks make it easy to create near-native UI for web apps. Sencha Touch aids in building applications for iOS and Android phones and tablets. It offers design of a rich user experience, but is more difficult to learn than some simpler JavaScript frameworks such as jQTouch. jQTouch is the better option when emphasis is on the development of web content.
  • Users can install a web app, adding it to their home screen with an icon and splash screens just like a native app.

Example of Sencha Touch: Kiva.org
There is a third option that allows developers to write apps with web technologies but get access to device hardware, device data, and App Store distribution: Hybrid Apps.


Combining web and native applications relieves some of the drawbacks of each type of app. This is done by “wrapping” the web app with a native app to gain access to more native features, such as some hardware features and iPhone resources (GPS position change, accelerometer, camera, audio playback and capture, etc). Like native apps, these applications must be distributed throughthe App Store, making them easier to find and monetize. PhoneGap is the leading framework for hybridization, with wrappers for multiple platforms, so the same core web app can be turned into a native iPhone, Android, BlackBerry, WebOS, or Symbian app.


The strengths and weaknesses of each approach mean each one is the best choice for some applications.


Use of web applications is the simpler option and more advantageous in certain situations. When hardware features are not required, except for, perhaps, a simple GPS, and only small amounts of on-phone data is required, using a web app is best. Similarly, when speed is not crucial, but portability between platforms is, use of web applications is the better choice.


If you want to design a deep, complex user experience, possibly for a game, want to use Apple’s high-level APIs, like developing with C-style languages, or need killer performance, go with a native app. If you want to work with well documented frameworks with lots of example code, for now, native apps are the best option. You’ll have to deal with memory management, pointers, and lots of delegate pattern use, the learning curve can be steep depending on your background.


If you want to share a codebase between devices or really prefer writing web apps but want to use App Store distribution or device hardware that isn’t normally available to web apps, a hybrid app fits your needs. If you’re used to writing web apps and want to put together a pretty standard app that needs to look like native UI, a hybrid app might save you a lot of time over learning Objective C.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: