Native vs Web vs Hybrid – Which is the best approach?

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

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: [9]

• high performance applications (i.e. heavy image processing);
• complex UIs with lots of animation;
• games (i.e. 3D).

Web

Web applications are accessed through the device’s browser and are usually developed in HTML and JavaScript. Web applications are easy to maintain as there is only one instance of the application being accessible from several platforms. Another benefit of using web applications is that the global standard created by W3C provides backward compatibility in such a way that HTML4 applications will work in HTML5-compatible browsers. The same cannot be said about applications developed for iOS 7 that are run on iOS 8. [12]

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. [13] 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. [14]

The last point to mention is performance. “Native apps do not have the web runtime barrier to deal with. They run close to the metal and can take advantage of performance boosters like GPU acceleration and multithreading.” [15] Poor performance used to be a big drawback of web applications, but a lot has changed in the last years. As one can see in Figure 1 and Figure 2, performance of mobile devices as well as interpretation of JavaScript and graphic rendering has improved significantly. [16, 17]

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.

Figure 1: Benchmark of mobile devices – scores are calibrated against a baseline score of 2500, which is the score of an Intel Core i5-2520M @ 2.50 GHz (higher scores are better) (ref: 18)

Figure 2: Performance of popular JavaScript engines based on Octane benchmark (lower scores are better) (ref: 19)

Hybrid

The hybrid approach combines the advantages of the native and web approaches. Hybrid applications are installed on the device in the same way as native applications. The only difference is that they are built with a combination of web technology, such as HTML, CSS, and JavaScript, and are hosted inside the application’s WebView (one can think of the WebView as a browser window that runs in fullscreen within the native application). This enables the application to access device services even though it is implemented as a web application.

Hybrid applications have the advantage of portability to different platforms. However, compared with web applications, they can still access device services which are restricted to access from inside mobile browsers. Hybrid applications consists of two parts – the web applications written in HTML, CSS, and JavaScript and hosted in WebView, and a wrapper that opens theWebView and provides JavaScript APIs for platform specific services such as an accelerometer or bluetooth. Figure 3 shows an architecture of the hybrid application.

Figure 3: Architecture of a hybrid application

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.

The main problem with hybrid applications is their performance. As mentioned in the previous section, the problem is becoming less significant as devices are becoming more powerful and JavaScript interpretation engines are becoming smarter and more optimized. At the time of writing this thesis, Apple introduced the new WKWebView that will improve the performance of hybrid applications running on the iOS platform by 20%. [20] Since version 4.4, Android has used the powerful Chromium web engine for its WebView and since version 5.0 has the ability to update WebView independently of the Android platform, resulting in the latest WebView version installed on all devices with Android version 5.0+. [21, 22] All the recent improvements indicate that the mobile platforms take hybrid development seriously and will keep optimizing their WebViews in order to provide even better
performance.

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.

It is important to mention that hybrid applications do not have to be built using web technologies. For example, the Xamarin project allows the application to be developed in C# and compiled to native applications. [23] The drawbacks are that one still need to build the UI for every platform the application is targeting, developers need to be skilled with C#, it supports only iOS, Android, and Windows Phone platform, and the community of developers is relatively small. Another project, Titanium, translates JavaScript directly into the native code of the device. The downside is that only iOS, Android, and Blackberry platforms
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]

Conclusion

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.

Table 1: Native vs. Web vs. Hybrid: 7 factors of comparison [26]

Bibliography

[9] H. Phan. Full-stack Mobile App With Ionic Framework. Hoc Phan, 2014.

[10] S. Truman. App Development: Learn Androids & iPhone App Development FAST! Az Elite Publishing Inc., 2014. ISBN: 973-332-00389-3.

[11] 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.

[12] 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).

[13] E. Bidelman. Capturing Audio & Video in HTML5. 2013. URL: http://www.html5rocks.com/en/tutorials/getusermedia/intro/ (visited on 03/30/2015).

[14] W3C. Device APIs Working Group. 2015. URL: http://www.w3.org/2009/dap/ (visited on 03/30/2015).

[15] M. Mahemoff. HTML5 vs Native: The Mobile App Debate. 2011. URL: http://www.html5rocks.com/en/mobile/nativedebate/ (visited on 03/30/2015).

[16] 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).

[17] 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).

[18] Primate Labs. iPhone, iPad, and iPod Benchmarks. 2014. URL: http://browser.primatelabs.com/ios-benchmarks (visited on 03/30/2015).

[19] AreWeFastYet: tracking performance of popular JavaScript engines. URL: http://arewefastyet.com/#machine=11 (visited on 03/30/2015).

[20] 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).

[21] 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).

[22] 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).

[23] Xamarin. Introduction to Mobile Development. URL: http://developer.xamarin.com/guides/cross-platform/getting_started/introduction_to_mobile_development/ (visited on 03/30/2015).

[24] 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).

[25] K. Whinnery. Comparing Titanium and PhoneGap. 2012. URL: http://www.appcelerator.com/blog/2012/05/comparing-titanium-and-phonegap/ (visited on 03/30/2015).