It’s interesting and appalling at times to see how this debate continues with strong opinions that simply add a silver line to a single development methodology in the mobile app space, some would pick native, some mobile web or some would now say hybrid is the “be all” for mobile development. The truth however has NO silver line attached to any one of these, there never was. Picking one of these approaches, as a universally optimum solution for all mobile business needs would be highly inaccurate, if anyone does it, it has to be a pure bias or personal preference.

Similar to the open ended world of web & enterprise technologies which does not have a single best technology stack or development methodology to fit all needs (no one can say that IBM Websphere Application Server is the best app server that exists or JBoss is the best java app container for any kind of web application), the mobile app ecosystem is no different because of the functional spread of the mobile landscape, from simple content rendering UI apps to ideas that integrate with the hardware & device components, varying level of complexities, user experience, business needs and philosophies which cannot be met through a single minded approach, at least not any more. The introduction of HTML5/CSS3 along with a series of high performing javascript frameworks (SenchaTouch, JQueryMobile, Dojo etc) & mobile hybrid platforms & run times (PhoneGap, Titanium, Adobe AIR & others) that allow you to wrap a mobile web app within a native shell, have opened up the development landscape. With an ever increasing fragmentation of the mobile OS market, the need for a cross platform compatible approach from businesses is compelling but on the same token there are certain strategies & ideas that can only be met through a completely native app. There will always be a market place for native, mobile web & hybrid development approach because they DO NOT always solve the same problem. This may not be the best analogy but I don’t see this any different from the way HTML & Flash was looked at a few years back. Not every creative need was solved by flash because it could do certain things that HTML could not – there was a need & place for both to co-exist.

Interestingly, despite of all the talk about what is “best”, there is still a lot of confusion and inaccurate common understanding about the different development methodologies especially when it comes to mobile web, it is used loosely to represent anything which is not native and that could be a huge mistake because you can do a lot more with a hybrid app that you couldn’t with just mobile web. Here is a quick explanation of the different approaches & key differences:

1. Native Mobile Apps

Apps designed & developed to run on a device’s operating system (OS) & firmware once installed. These are coded separately with a programming language for each OS (Objective C for iOS, Java for Android & Blackberry, C++ for Symbian) to adapt to the device needs. In general, mobile functionality can be viewed as two broad buckets: the experience of the app and the way it hooks into the device’s ecosystem, native apps excel in both.

• UI | Look & Feel – The user interface is cleaner with multiple widgets & components, ideal for complex & high end graphics and faster speed due to their closeness with the actual OS & device hardware – there is no separation. They benefit from easy event recognition, anything from swipes, multi-touch, key press to search or volume control.
• Native Features & Device Integration – Native apps can easily access hardware components like GPS, camera, audio or even the file system. With adequate permission, some platforms provide additional hooks into the operating system to detect battery life as well – good luck trying that with a web or hybrid approach. Developers can make use of notifications that show up in the device’s status bar or intents, which allow your app to announce itself as providing a general service which other apps might require on occasion.
• Performance & Offline Mode– Native apps enjoy optimum performance because they don’t have to deal with the web or browser runtime, they run close to the OS and usually take advantage of performance boosters like GPU acceleration and multithreading. They can use device caching and extensive data storage that not only prevents a webservice call to fetch data every time but also provide an “offline” mode for the app.
• Monetization & Discoverability – Native apps can easily be distributed and monetized through apps stores & market places and can be searched by user community from mobile devices & tablets. Mobile platforms allow developers to directly charge for the apps – one time payment for the install or a possible in-app payment or subscription model for an ongoing revenue stream.
• Challenges – The flip side to all of this however is the additional cost to build the same app across multiple devices & OS which can continue to grow as more OS become successful and marketers go beyond the usual iOS & Android options – keep an eye out for the new Windows 8 look to create a foothold OS distribution. Besides the cost it is the varying technology skills that are needed to cover the OS distribution.

2. Mobile Web or Mobile Website or Mobile Web Apps

Yes, they all mean the same – anything that renders in a mobile web browser, mostly using web technologies like HTML5 & CSS3/Javascript.

• UI | Look & Feel – This could be a CMS driven site or a static content based marketing presence for a brand with a visual design that adheres to mobile standards (button sizes on a mobile page for instance are different than the design for a PC version, page resolutions are different as well based on device screen sizes). A mobile website can be in synch with the PC version from a creative standpoint, usually containing a sub set of functions & features and other differences in resolution, general mobile friendly design and navigation. It can benefit from a common platform (between mobile & PC) with the same content & interface layer for any business logic. A simple device detection logic can be used that renders the presentation based on the device, a visitor on a PC sees the normal website whereas the visitor from a smart phone or tablet sees the mobile website. Of course, you could also build a completely separate mobile site with its own CMS (or no CMS if you prefer).
• Native Features & Device Integration – There are no native hooks available through the browser, a complete lack of integration with device’s native features. The extent of mobile experience is limited to touch events that can be achieved through javascript libraries & frameworks like swipes, multi-touch, pinching.
• Performance & Offline Mode – The performance of the mobile experience is comparable to that of the desktop version. The apps depend on web access to pull content from the server through a series of HTTP requests every time the app or the web page is loaded. There is a lack of local caching and data storage options which increases the dependency on real time web requests to render content.
• Monetization & Discoverability – Besides the UI difference, there is no other difference between a mobile web or a regular website, both can be hosted on the same server, both are accessible by search crawlers & optimized for SEO which makes them searchable through search engines. Because these are completely web based, these are not available on the app store or android market place.

3. Hybrid Mobile Apps

Simply & literally a hybrid approach which couples the broad support of web-based apps with the richer features of native, the main content & presentation of the app is displayed using the webview which renders on the browser but can be wrapped in a native shell. The advantage over native is the cross platform & device compatibility, do not need to be managed and maintained for different mobile operating systems – in reality, there is still some effort to make the experience smooth across all devices but it is not ground up and far less as compared to writing a completely new native app.

• UI | Look & Feel – The components in the UI are not the usual native widgets but instead code written in HTML5/CSS3 which renders on the browser – assume this is one large widget wrapped by a shell provided by frameworks like PhoneGap (recently acquired by Adobe), Titanium, Mosync, Corona and others. An HTML5 & CSS3 code helps create a web like interface on the app, can be aligned with the desktop browsing experience. Having said that, there are certain javascript frameworks like SenchaTouch, JQMobile that provide UI widgets or components which are native looking and lend a more device like experience to the hybrid apps.
• Native Features & Device Integration – The hybrid frameworks come with native hooks into the platform and device features like the GPS, camera, notifications, file system, intent etc. These hooks are exposed through javascript APIs that get called through the webview object. Developers write a web app but get access to native functions through a javascript layer resulting in a native looking app & experience built using web technologies which is also cross OS compatible.
• Performance & Offline Mode – Performance benchmarks are subjective, response time expectations can vary based on the design & user interface of the app. Having said that, we cannot compare the performance of a hybrid app with native since a hybrid app has to deal with a browser runtime, however not every app or idea is performance centric as long as the user experience is smooth and there are no delays or wait for the user. Besides that, a series of newer javascript frameworks, graphic rendering engines, multi-threading options using web workers and other performance optimization guidelines for web have boosted the overall web experience. There are lesser known open source frameworks like Backbone, Underscore which are redefining how data is managed between DOM, UI & server side layer for more efficient processing. Not to mention node.js or “node” which has evolved network & server side programming, brings a server side solution for javascript which integrates or feeds into node’s server side capability & functions (node itself isn’t javascript but a C program). Hybrid apps also support offline mode, data storage can be achieved using SQLite for instance but there are limitations to the amount of data that can be stored.
• Monetization & Discoverability – Hybrid apps follow a very similar path as the native apps. Because the apps are packaged as “native” app extensions ie .ipa for iOS, .apk for Android, they are uploaded into the App Stores & Market Places the same way as their native counterparts. From a consumer standpoint as well, they may not even discover the technology underneath, whether it is built using a native language or a hybrid approach. The apps can be discovered and searched through the usual app store model and can be found & installed through the mobile & tablet devices with a very similar monetization model as well.
• Examples – Some real world examples of hybrid apps includes IGN’s social network Dominate, the “Facebook” mobile app believe it or not, Microsoft’s Bing for Mobile, Linkedin & Netflix apps and many others.
• Challenges – You can build once & publish everywhere & developers benefit from accessing native features using web technologies but there are limitations to these benefits primarily around performance, local data storage, level of graphic interface and the extent of native integration as compared to a completely native app. Even though the methodology supports multi-OS & multi-device compatibility, there is still some work that may have to be done from a UI standpoint to make the experience completely consistent across devices.

Adobe AIR

This deserves its own write-up but the hybrid approach would be incomplete without the mention of Adobe AIR – Adobe’s cross platform runtime environment (not just a framework) which was originally designed to build rich internet applications (RIA) for desktops but has now been extended to support mobile platforms & operating systems like iOS, Android, Blackberry with web technologies like HTML, javascript, ActionScript, Flex & Flash (yes you can package Flash applications& build them with Adobe AIR to make them mobile compatible and use native device features like file system, GPS, accelerometer etc) using the Adobe SDK. Similar to native apps, these are installed on mobile devices and run without the browser run time unlike the predecessor Flash Player approach which was dependent on the browser. Similar to a java virtual machine (JVM) for java applications, the Adobe AIR Runtime needs to be installed on the device to allow execution of the app & display the content using its WebKit HTML renderer. Operating systems like Android would automatically install the Adobe AIR when an Adobe AIR app is launched the first time however an iOS device would require the app to be downloaded along with the runtime as a complete package. This is Adobe’s effort to push HTML5 & PhoneGap hybrid approach while Flash packaged with Adobe AIR is designed to target advanced gaming, 3D Graphics and other mobile ideas. While there are cross platform & usability benefits in using Adobe AIR, performance, CPU & battery consumption, app sizes are some of the common challenges that should be taken into account.

What is the right approach for me?

It is almost impossible or inaccurate to pick one from the pack without referring to the business needs, specific requirements around the app and overall mobile strategy. A few guidelines that may be used:

• General Guideline – Even though as subjective as it is, it is relatively safe to say that apps that are content driven, rely on the web like news, catalogs, digital magazines, social networking etc can benefit from web or hybrid approach. Whereas apps that require gaming, rich graphics & high dependency on device features like microphone, camera, speaker, file system, offline data storage, vibrations etc should go the native route.
• User Experience | Look & Feel – Native look vs web oriented, do you need rich graphics or a simpler web like experience
• Device Integration – An idea that depends “highly” on device’s native features & components may benefit from a native approach especially if it requires file system, audio, local data storage, vibration, speaker etc.
• Performance – Not every idea needs lightening speed. News, content, social networking, digital magazines kind of ideas can benefit from the hybrid or web approach. However high speed games, rich graphic or apps with strong device feature dependency should go the native route for better performance.
• Device based caching & offline mode – Based on the volume of data to support the offline mode, native could be a better option
• Discoverability – Native & hybrid follow a similar path but a mobile web idea can benefit from standard web based search engines
• Technology skills – Web technology skills vs native language support for different platforms
• Cost of build & maintenance – Build once & publish everywhere vs build & support for multiple platforms at the cost of certain rich features

Conclusion

Unfortunately there isn’t a clear winner and there may not be one any time soon. If native holds an edge in terms of advanced user experience & device proximity, web is growing fast in these areas too and gaining huge momentum in the hybrid space. The increasing fragmentation of the mobile platform landscape establishes the case for a cross platform solution but certain ideas can only be native. Like any other enterprise technology solution needed to solve a business problem, a strategic mobile solution needs enough upfront effort & research to determine the most optimum development approach & methodology and this exercise should not be undermine.