Comparing and Contrasting Native and Hybrid (HTML5) Mobile Apps

Joe Sauve

Feb 3, 2015 • 12 min read

Summary

The development of mobile apps presents many challenges, the primary being:

How does one ensure that the deliverable of the development process is an app that experiences pervasive and positive engagement with the target users?

In other words, how do I make sure that I create an app that people want to use?

The answer to this question comes from a mix of several disciplines, arguably the most important of which are: 1) user experience (UX) design, and 2) software development. For the purposes of this post, it is assumed that good high-quality UX design is a given. This means that in all development scenarios, we are assuming that the UX designers involved have a proven track-record of designing successful and engaging mobile apps. However, even given that assumption, a central focus of this report will center on UX. This is because a positive and engaging app is not only dependent on seasoned UX experts, but also the way in which that UX is technologically delivered to users.

The Mobile Landscape

The current mobile landscape is clearly dominated by two primary players: Apple’s iOS devices and Google’s Android devices. By and large, the form factor of these devices is still the “smartphone.” Tablets, wearables, and implants, while interesting and novel, are not ubiquitous in the way that the smartphone is. These two dominant operating systems (iOS and Android), and their accompanying dichotomy of supported phone hardware, present unique and significant challenges to those who wish to develop meaningful software that targets mobile users. The science (and art) of overcoming those challenges is known by two names: 1) multi-platform development and 2) cross-platform development.

Multi-platform and cross-platform are distinctly different approaches to solving a single problem: creating an engaging and positive mobile app user experience for more than one mobile platform. The multi-platform approach seeks to solve the problem by separately writing an app that will run on each targeted platform: one app for iOS, and another separate app for Android. This approach is characterized by developing in different programming languages and using a different set of development tools for each platform.

Cross-platform, on the other hand, seeks to solve the problem by using a single programming language and using a single unified set of development tools. The cross-development approach outputs a solution that is intended to target more than one platform, but has been accomplished with a simplified development process.

Redefining “Native”

It is commonly regarded that the result of multi-platform development is a “native” app, and the result of cross-platform is commonly not a native app. However, this is a false and misleading definition. It is important that we take a moment to clearly define what is meant by “native”.

The typical understanding of “native” is an app that has been developed using the programming language, tools, and guidelines set forth by the platform maintainer. In the case of Apple, this means an iOS app that has been developed in either the Obj-C or Swift programming languages, using the Xcode development toolset, and follows user interface guidelines set forth by Apple (known as the iOS HID (human interface design) guidelines). Similarly, in the case of Google, it means an app that has been developed in the Java programming language, using one of a variety of development toolsets (Android Studio, IntelliJ, or Eclipse), and follows the Android user interface guidelines. These are the typical (and misleading) understandings of what is meant by a “native” app when it comes to iOS and Android.
A brief note on Microsoft mobile devices: Microsoft’s Windows Mobile operating system and devices have a similar collection of development paradigms as iOS and Android, but because their market share is so low, they will not be considered in this post.

After having clarified the typical definition of “native”, it must henceforth be understood that the definition is WRONG. It is a misnomer to consider only the aforementioned “native” definition as being “native”. The more accurate definition of a native mobile app is:

Any mobile app that has been developed in such a way that the end result of the development process is an app package (.APK for Android, and .APP for iOS) that runs directly on the device, and has the ability to use the full breadth of the APIs that the mobile platform offers.

This new definition means that:

An app does not need to use the programming language(s) prescribed by the platform maintainer.
An app does not need to use the development toolset prescribed by the platform maintainer.
An app does not need to follow the user interface guidelines of the platform maintainer.

Stated another way, this means that:

Non-prescribed programming(s) language may be used to develop the app.
Non-prescribed development toolsets may be used to develop the app.
The user interface guidelines may be whatever the designer chooses (provided that, in the case of Apple, the app passes the approval process).

However, the following constraints must remain:

The development MUST result in an app package that runs on the device, i.e. an app that can be downloaded from the app store (not a web app that is accessible only by a URL).
The app developer MUST have access to all of the APIs provided by the platform maintainer. If any of the platform APIs are unavailble to the developer, the resulting app is not a native app.

Using this new definition of “native”, we can proceed with our discussion and compare and contrast native and hybrid (HTML5) mobile apps. However, instead of referring to these as the “old” native definition and the “new” native definition, we will refer to them as language-native and platform-native, respectively. Language-native adheres to the opinion that the maintainer’s languages and tools must be used, whereas platform-native has only the constraints that there must be a valid app package produced, and that all of the platform APIs must be available to the developer.

Considering our clarified definitions, we can go back to the two primary philosophies (multi-platform and cross-platform) and see that language-native development lends itself well to the multi-platform philosophy. Multi-platform takes the opinion that development should be performed for each platform separately, and using a language-native approach aligns strongly with this.

Cross-platform, however, takes the opinion that language-native is a constraining (and wasteful) approach. The question then becomes:

How is cross-platform development performed?

The answer to that question is complex, but also exciting, with many opinions and possibilities.

Cross-platform App Development

When considering the definition of platform-native, it is natural to at first ask:

How is it possible to develop an app that does not adhere to the platform-maintainer’s prescribed development methodology of languages, tools, and design guidelines?

The answer to that question is the same as it is for most computer science problems: abstraction.

Two major cross-platform abstraction approaches have arisen in the field of mobile development:

Developing an app that takes advantage of the web browser on smartphones and uses web standards to create a web app that runs across multiple platforms by virtue of the browser, or
Developing an app that uses some other third-party language and toolset to communicate directly with the platform APIs on the device at runtime.

The first is what is considered an HTML5 or hybrid app, and the second is what would be considered an app that adheres to our new platform-native definition.

The interesting thing about the HTML5/hybrid approach is that many of the platform APIs are actually accessible, such as camera functionality, location services, accelerometer, compass, contacts, file system, etc. However, at this time, HTML5/hybrid apps do not provide access to 100% of the platform APIs, such as core graphics or other native UI APIs. For an example of the types of APIs that can be available to HTML5/hybrid apps, see the device API compatibility list for Cordova, a framework that serves as the basis for several other HTML5/hybrid mobile frameworks.

Examples of other HTML5 mobile frameworks, some of which rely on Cordova, are:

Phonegap: http://phonegap.com/
Sencha Touch: http://www.sencha.com/products/touch/
Intel’s App Framework: http://app-framework-software.intel.com/
Kendo UI: http://www.telerik.com/kendo-ui

Despite the fact that an HTML5/hybrid app does not have full access to all of the APIs provided by a given platform, the output is indeed an app package that is distributable via app stores. This is accomplished by creating an app package that essentially consists only of a “webview”. A webview is a browser window that has no “chrome”: no title bar, no address bar, no buttons, no bookmarks, no scrollbars, no footer status bar, etc. A blank webview appears as a rectangle that takes up the entire screen on the mobile device. It is inside this webview that an HTML5/hybrid mobile app “runs”, thus creating the appearance of a “native” app. Mobile apps usually consist of many different kinds of UI components, such as view controllers (iOS), activities (Android), modally presented views (iOS and Android), webviews(iOS and Android), etc. As you use a typical mobile app, you switch between these different types of UI controls as you navigate through the app. But in an HTML5/hybrid app, there is only one control: the webview.

In contrast, true platform-native mobile frameworks provide access to 100% of the APIs that a given mobile platform provides. The primary advantage of platform-native frameworks is that they provide the ability to write the app for multiple platforms using a single programming language and toolset, and the app code executes at runtime on the device operating system itself, not in a browser. The resulting app will contain all manner of UI controls that are offered by the given platform, not only a webview.

This ability to use one language and yet still produce a fully API-accessible app package is generally accomplished by marshalling. In computer science, marshalling is the activity of allowing communication between two systems that may be vastly different. This is similar to serialization, but at a lower and faster level. For example, Microsoft’s .NET framework has a facility known as “InteropServices” that, for example, allows C# code to execute C++ or C code. Essentially, InteropServices allows using one language to “wrap” an API that only exists in another different language.

In fact, this is exactly how one of the leading platform-native frameworks, Xamarin, accomplishes cross-platform mobile. When you pay for Xamarin, what you get is two C# libraries: Xamarin.iOS and Xamarin.Android. The Xamarin.iOS library completely wraps every single API call from the native Apple iOS Obj-C SDK. The Xamain.Android library completely wraps every API call from the native Google Android Java SDK. Along with an optimized C# runtime that runs on both iOS and Android, the beauty of Xamarin is that developers write 100% C# code that executes on either platform. In fact, large swaths of that code don’t even need to be re-compiled: a DLL file from an iOS phone can literally be plucked out and placed on an Android phone, and it will run exactly the same (provided that the DLL is a portable class library). What this means is that enormous portions of the app code can be shared between platforms, and run at native speed. And with the new Xamarin.Forms framework recently released by Xamarin, an app can be written with 100% shared code, even the UI code. This means: a single codebase, running an app on multiple platforms, at native speed. Pretty much the holy grail of software develoment.

Examples of platform-native frameworks are:

Xamarin: http://xamarin.com/
Appcelerator Titatnium: http://www.appcelerator.com/
NeoMAD: http://www.neomades.com/en/
Xamarin + MvvmCross: https://github.com/MvvmCross/MvvmCross

API Convergence

Upon observing the differences between HTML5/hybrid and platform-native apps, an important realization becomes obvious:

If both approaches can access most of the important device APIs, such as location services, contacts, storage, accelerometer, and camera, then how are they different? Why would I choose one over the other? Why would I choose to build an app using a platform-native approach as opposed to a HTML5/hybrid approach?

The short answer is: UI APIs.

With HTML5/hybrid, the app runs entirely inside the browser. Essentially, the browser is the runtime for the application. This means HTML5, javascript, and CSS are all running in the browser. The only app calls being made to the operating system are through the javascript APIs provided by the HTML5/hybrid framework, like Cordova or Sencha Touch.

With platform-native, the entire application runs much “closer” to the operating system, not relying on the browser’s rendering engine to present the UI. Whether or not this provides better performance than HTML5/hybrid...is a topic of highly contested debate. It can be difficult to compare the two directly, and depending on the use case, one may present advantages over the other. But in general, platform-native is regarded as providing smoother and more performant mobile app user experiences. [1] [2] [3] [4] [5] [6]

But the fact remains: the APIs for device functionality are converging. Much of the device functionality that a platform exposes is available not only to platform-native apps, but also HTML5/hybrid apps as well.

User Experience is King

Given that the major differentiating factor between platform-native and HTML5/hybrid apps seems to be the way in which UIs are constructed and presented, what factors determine the decision to choose one over the other? For many business analysts and managers, the immediate conclusion would be cost. There is definitely a wide variety of costs involved in the plethora of available mobile frameworks, ranging from free to exorbitant. But if stakeholders are truly concerned about the adoption of their app(s) with their target audience (and likely, customers), there is one glaringly important factor that must be considered: User Experience. Users are fickle, and they'll drop an app like a bad habit if it doesn't delight them, or worse, if it gets in their way.

User experience is something that can be difficult to quantify. But the best way in which to measure it is through user feedback and automated metrics collected from apps running in the real-world.

A high-profile example of this is the mobile app developed by Facebook. Facebook made early investments in HTML5 as the future of their mobile app platform. The company spent great sums of money building out the primary mobile interface to their users, betting on HTML5 being the silver bullet to once and for all solve the cross-platform mobile challenge. Facebook’s mobile engineer, Jonathan Dann, cited that while HTML5 helped Facebook reach a wide audience in a short period of time, the performance and user experience weren’t acceptable, and the company subsequently switched back to native for their mobile app.[7] Facebook does, however, continue to use HTML5 within their app for rendering new types of content when the mobile app has not yet received an update to support those new content types.

While HTML5 may not have been the right secret sauce for Facebook, it may be for other applications. The lure of HTML5 is that it can have a low barrier to entry, leveraging the web development skills of existing developers, and being able to target a wide variety of devices. But the performance question still looms as a possible deterrent. At the time of this writing, a Google search for “native vs html5” (for the last 12 months) yields a vast majority of top results that cite native is still leading HTML5 in performance and adoption. This is in spite of industry forecasters predicting two years ago that, by this time, HTML5 would be the obvious choice.

Another very recent example of this is Microsoft’s replacement of its Outlook Web Access (OWA) HTML5/hybrid mobile app with the brand new native Outlook mobile app.[8] The switch to native from HTML5, and the resulting strongly positive reviews of the new app, underscores the trending opinion that native is still leading HTML5 in mobile user satisfaction.

Developer Experience...also King

Another important consideration to mobile development stakeholders will certainly be the development labor resources. Developers will ultimately be the individuals putting the “rubber to the road”, writing the code that makes up the app.

A recurring theme is emerging from the experiences of numerous app development efforts over the last few years: the toolsets for building HTML5 apps simply aren't at the level of native toolsets. This translates into more bugs with a limited ability to resolve them, longer development iterations, and increased time-to-market. This is a notable paradox to the marketing messages that HTML5 frameworks tout as solutions to these very problems.

A high-profile example of this is the LinkedIn mobile app. The app was originally released in HTML5 as a hybrid app. However, in Q2 of 2013, LinkedIn replaced its HTML5 app with a native one. When asked why, LinkedIn’s senior mobile engineering director Kiran Prasad, in addition to citing performance problems, also stated that the tools available for debugging and profiling simply don’t provide developers with the insights they need to develop HTML5 apps that are at the same caliber as native apps.[9]

For proponents of HTML5, this is sure to be disappointing. In the same Google search of “native vs html5” for the past 12 months, the tooling complaint is as common as that of performance. It seems that although HTML5 as an app platform sounds like a great idea at first, there are nuances that are not immediately visible that tend to be impediments at best, and show-stoppers at worst.

Visualizing the differences

The following is a comparison matrix of some important mobile features, and how they're supported by different mobile development strategies:

Conclusions

It’s clear that mobile development is not clear. However, in cutting through jargon, evaluating the experiences of others, and comparing the features of different solutions, it is possible to make good decisions about mobile strategy. At the time of this writing, it appears that platform-native solutions have the potential to provide the greatest value:

Cross-platform shared code
Target multiple platforms
Decrease time to market
Improve maintainability efforts
Native performance
Superior user experiences
Full platform API availability

As with any software solution, the current and future requirements should be evaluated when making a decision about strategy. This is no less true when evaluating a mobile strategy.