Mobile application development can be a very complex and challenging task due to the variation of mobile platforms (iOS, Android, Windows Phone). As a result, different development approaches have emerged and we must make an informed decision about which one to use.
Native applications are written in the native language of the platform (Objective-C for iOS, Java for Android, C#/.NET forWindows Phone). They have direct access to native services, such as cameras, through the API provided by the platform’s SDK. The platforms SDKs also provide user interface components such as animations, dialogs, gestures, tabs, or menus, and, as a result, each platform has its own unique look and feel.
The main advantage of native applications is their performance. Native code is compiled and runs at a low level, allowing developers to build computing intensive applications or applications with complex animations. A disadvantage of native applications is their portability – they can only run on the platform they were developed for. From the user interface perspective, no two platforms have the same or even similar paradigm, therefore most of the code will have to be rewritten with little able to be shared. In a nutshell, native code development can be a very complex task that requires developers skilled in each of the platforms. On the other hand, it offers the best in terms of performance. [9, 10]
What makes things even more complicated are the differences among the actual platform SDKs (software development kits). There are different tools, build systems, APIs, and devices with different capabilities for each platform. In fact, the only thing these operating systems have in common is that they all ship with a mobile browser that is accessible programmatically from the native code.
– Ref: 11
In general, native development approach is usually used when we need to build the following: 
- high performance applications (i.e. heavy image processing);
- complex UIs with lots of animation;
- games (i.e. 3D).
Web applications are not installed locally on the device (are not distributed via app stores) and must be accessed from the Internet. This becomes a problem in places where there is no or poor Internet connection. Their graphical user interface is completely rendered in the browser and dependent on the type and version of the browser used, requiring more thorough testing.
The biggest drawback of the web approach is the lack of integration with device services such as bluetooth, a microphone, or camera. Although HTML5 comes with Geolocation API (gps) and Orientation API (accelerometer), and allows for image uploads using a built-in camera, its support in today’s browsers is still only partial.  Although W3C is actively working on standards for client-side APIs that would allow browsers to access device services such as a calendar, contacts, or battery status, it will be some time before the majority of browsers adopt them. 
In general, the web development approach is usually used when we need to build:
- multi-platform applications;
- applications that do not need access to device services such as cameras or bluetooth;
- non-intensive computing applications;
- applications that do not need to be distributed through app stores.
As web technologies are becoming well standardized and familiar to many developers, it makes the development of hybrid applications more rapid and easier to maintain. Hybrid frameworks like Apache Cordova let one build the application for more than one platform just by adding a line of code. Developers do not like to get locked into proprietary platforms and hybrid applications allow them to reuse their existing web development skills.
In general, the hybrid approach is usually used when one needs to build:
- multi-platform applications;
- applications that need to access device services such as cameras or bluetooth;
- non-intensive computing applications;
- applications that need to be distributed through app stores.
are supported, and that many developers consider titanium to be very buggy, which leaves applications with unpredictable behavior. Consequently, I decided not to write about these technologies, even though they might be a good fit for some projects. [24, 25, 9]
I described the different approaches to mobile application development. Each approach has its particular advantages and disadvantages (Table 1 provides an overall comparison). It is important to realize that the decision about which approach to use can have a huge impact on the overall architecture of our application. If we expect that the application will not have to do any heavy computation nor extensive image processing and the development team is skilled in web technologies, hybrid approach is usually a good option as it has lower costs and provides better portability.
|Cost||Commonly the highest of the three choices if developing for multiple platforms||Similar to pure web costs, but extra skills are required for hybrid tools||Lowest cost due to single codebase and common skillset|
|Code reusability / portability||Code for one platform only works for that platform||Most hybrid tools will enable portability of a single codebase to the major mobile platforms||Browser compatibility and performance are the only concerns|
|Device access||Platform SDK enables access to all device APIs||Many device APIs closed to web apps can be accessed, depending on the tool||Only a few device APIs like geolocation can be accessed, but the number is growing|
|UI consistency||Platforms comes with familiar, original UI components||UI frameworks can achieve a fairly native look||UI frameworks can achieve a fairly native look|
|Distribution||App stores provide marketing benefits, but also have requirements and restrictions||App stores provide marketing benefits, but also have requirements and restrictions||No restrictions to launch, but there are no app store benefits|
|Performance||Native code has direct access to platform functionality, resulting in better performance||For complex apps, the abstraction layers often prevent native-like performance||Performance is based on browser and network connection|
|Monetization||More monetization opportunities, but stores take a percentage||More monetization opportunities, but stores take a percentage||No store commissions or setup costs, but there are few monetization methods|
Table 1: Native vs. Web vs. Hybrid: 7 factors of comparison 
 H. Phan. Full-stack Mobile App With Ionic Framework. Hoc Phan, 2014.
 S. Truman. App Development: Learn Androids & iPhone App Development FAST! Az Elite Publishing Inc., 2014. ISBN: 973-332-00389-3.
 A. Charland and B. LeRoux. “Mobile Application Development: Web vs. Native”. In: Data 9.4 (2011). URL: https://queue.acm.org/detail.cfm?id=1968203.
 B. Lawson. HTML5: The Facts And The Myths. 2010. URL: http://www.smashingmagazine.com/2010/09/23/html5-the-facts-and-the-myths/ (visited on 03/30/2015).
 E. Bidelman. Capturing Audio & Video in HTML5. 2013. URL: http://www.html5rocks.com/en/tutorials/getusermedia/intro/ (visited on 03/30/2015).
 W3C. Device APIs Working Group. 2015. URL: http://www.w3.org/2009/dap/ (visited on 03/30/2015).
 M. Mahemoff. HTML5 vs Native: The Mobile App Debate. 2011. URL: http://www.html5rocks.com/en/mobile/nativedebate/ (visited on 03/30/2015).
 K. Millikin and F. Schneider. A New Crankshaft for V8. 2010. URL: http://blog.chromium.org/2010/12/new-crankshaft-for-v8.html (visited on 03/30/2015).
 P. Chandna. Hardware-Accelerated Chrome 7 60x Faster than Previous Versions. 2010. URL: http://www.maximumpc.com/article/news/hardware -accelerated_chrome_7_60x_faster_previous_versions (visited on 03/30/2015).
 Primate Labs. iPhone, iPad, and iPod Benchmarks. 2014. URL: http://browser.primatelabs.com/ios-benchmarks (visited on 03/30/2015).
 TJ VanToll. Why iOS 8’s WKWebView is a Big Deal for Hybrid Development. 2014. URL: http://developer.telerik.com/featured/why-ios-8s-wkwebview-is-a-big-deal-for-hybrid-development/ (visited on 03/30/2015).
 M. Firtman. Android 4.4 KitKat, the browser and the Chrome WebView. 2013. URL: http://www.mobilexweb.com/blog/android-4-4-kitkat-browserchrome-webview (visited on 03/30/2015).
 R. Coles. Beta Channel for the Android WebView. 2015. URL: http://blog.chromium.org/2015/02/beta-channel-for-android- webview.html (visited on 03/30/2015).
 Xamarin. Introduction to Mobile Development. URL: http://developer.xamarin.com/guides/cross-platform/getting_started/introduction_to_mobile_development/ (visited on 03/30/2015).
 A. Dallera. Why you should stay away from Appcelerator’s Titanium. 2011. URL: https://usingimho.wordpress.com/2011/06/14/why- you- shouldstay-away-from-appcelerators-titanium/ (visited on 03/30/2015).
 K. Whinnery. Comparing Titanium and PhoneGap. 2012. URL: http://www.appcelerator.com/blog/2012/05/comparing-titanium-and-phonegap/ (visited on 03/30/2015).