Mobile sales tools

Hybrid Mobile Applications: Is Webview or Native Right For Me?

An Introduction to Hybrid Mobile Apps

Mobile application development is hard.

It is made even harder by the fact that there are an overwhelming amount of devices that your application must support in order to cover one platform. A new iPhone device and multiple Android devices are being released every year. Throw in operating system updates every couple of years and you have a recipe for a digital agency’s worst nightmare.

Agencies that would like to maintain long, healthy relationships with their clients are forced to walk in a minefield of engineering problems because there are no universal standards in the mobile application development world. This can make mobile application development expensive and resources difficult to find.

I know what you’re thinking: “That sounds really expensive and I don’t know if my small- to mid-size business can afford to develop for more than one platform.”

You may be surprised to discover that technology developed within the past 5 years has made it substantially easier to develop an application for multiple platforms at once. You may also be surprised to find out that it is possible to leverage your web development knowledge to build such an application.

In this article, we will be exploring the state of hybrid mobile application development. We will be comparing two different development methodologies: webview-based development and native-based development.

Webview-based hybrids, built with frameworks like Cordova and Ionic, have come a long way since their introduction and offer relatively easy, rapid prototyping – albeit with two significant shortcomings.

Native-based hybrid development, with React Native, is a new way to build applications using JavaScript and a device’s own library of native components.

Webview-Based Hybrid Applications

Created at a developer camp event in San Francisco, PhoneGap is a framework that allows developers to create mobile applications using web technology such as HTML, CSS, and JavaScript. The creators of this framework purport that Apple, and other smartphone designers, had only half of a good idea when they created the mobile web SDKs for their devices as they neglected to include interfaces for developers to access all of the helpful native features such as geolocation and accelerometers. PhoneGap picks up the slack and allows the developer to interface with these native features from within the native mobile web component. The end result is an application that can be packaged and distributed on a native application store as if it were developed the traditional way. Since all major platforms offer some sort of webview component, the application’s code base can be written once and distributed on multiple platforms. PhoneGap has since become the open source Apache Cordova.

Taking it one step further, open source software development company Drifty has created a component based framework leveraging Cordova and Angular. The Ionic Framework creates an ecosystem where preconstructed, native-looking web components can be pieced together to create visually modern mobile interfaces. The bells and whistles are too many to list here, but we definitely recommend checking it out. The Ionic ecosystem is so easy to use that it has given birth to a massive developer community that has created an impressive 1.3 million apps in 2015 alone. Since they’ve shifted branding from Drifty to Ionic, the team has released the second version of the framework. This time around, developers can take advantage of the improvements of Angular 2, as well as create flexible, reusable components via compiled TypeScript. Additionally, Angular 2 ditches the dirty checking and digest cycles of Angular 1 making it much more performant.

So now you’re thinking to yourself: “This is great! Now my web development team can build cross-platform mobile applications in half the time it would take for a full-time iOS and full-time Android development team.”

In theory, that is correct. In practice, it is a little more difficult. There are two primary considerations:

Webview Consideration #1: Performance

When Cordova was first gaining popularity, the commonly used webview component was UIWebView, which Cordova uses by default. Since then, the new and improved webview component, WKWebView, has been integrated into the Cordova ecosystem as a plugin. While this allows the developer to increase the speed and smoothness of their webview based application, it will not match the performance of native components.

To further complicate your “build once, deploy everywhere” quest: each Android device has its own default webview. This means that there is no way to be certain that you will have access to certain JavaScript APIs, certain CSS properties, or even that the application will render the same on all devices. Fortunately, some caring soul created Crosswalk to make sure the webview your app uses is based on Google Chrome’s latest webkit engine.

Webview Consideration #2: Updates

Those who aren’t familiar with the hardships of mobile application development will struggle to understand why building it once and forgetting about it is not an option. Mobile applications are living things.

Personally, I find that the biggest problem with webview-based hybrid apps is keeping up with the problems that are introduced when new devices or operating systems are released into the wild. They need to be constantly updated in order to function correctly on the latest device and/or operating system.

For example, say you need to send an email from your mobile application. The native email composer component could change from one version of the operating system to another. This would require the authors of the Cordova email composer plugin to update their plugin before application developers can once again access the native component without issue. This means that certain application features could break for weeks or months at a time before the application developer can fix the problem. If your agency is trying to maintain a healthy, long-term relationship with clients, then webview based hybrid applications may not work out so great.

Native Component-Based Hybrid Applications

One of the more exciting recent developments in mobile application development has been the advent of hybrid development solutions that utilize native components for a truly native experience. The main contender here is React Native. Using React Native, the developer can use JavaScript and a JavaScript syntax extension called JSX to construct their application from a library of native components. These components are abstracted from native components on both iOS and Android. Therefore, the developer can reuse the codebase of the iOS application for the Android application with minimal tweaking.

This is great because the developer is no longer hampered by the burden of a less-than-ideal webview component. Front end developers who are not familiar with React Native components can utilize existing boilerplate kits such as NativeBase in order to easily construct cross-platform applications that adhere to the native look and feel of the platform. Time will tell if native component-based hybrid applications will result in a community as prolific and active as the webview-based hybrid application developers.

If you’re considering going with native, here are two important things to consider:

Native Consideration #1: Industry Support

React Native, having been developed by Facebook, has an advantage over webview-based hybrid applications because it is supported and actively used by some of the largest names in the industry. This may seem trivial, but the fact that big names such as Airbnb and Discord are using React Native in their production applications is a testament to its power and stability in quickly moving development environments.

Native Consideration #2: Which is better, React or Angular?

At first glance, it seems that React is lagging behind as Angular is leading in almost every single market metric according to Similar Tech. While this may seem like an argument in favor of Angular, Similar Tech does not specify whether this includes websites making use of Angular 1. Regardless, Angular and React are very different and comparing them is akin to comparing apples and oranges. Angular is a framework and with that comes a commitment to the framework’s opinions and a steeper learning curve. React is not a framework as it is only relevant to the view layer as stated on their home page.

In their Angular 2 vs React Dance Off, Medium has an excellent breakdown of the implications of embracing TypeScript, an Angular preference, in your development process. The author provides some convincing arguments for why the overhead may outweigh the benefits. However, both Angular and React can be used with or without TypeScript. React’s JSX has its merits. One such merit is the fact that React can target markups other than HTML; a really forward thinking approach to front-end development.

In terms of state management, both libraries are flexible. React lends itself well to state management via Redux. This approach makes it easier to implement undo and support time-travelling for more elegant debugging. Angular, however, can also use a Redux-esque paradigm.

So… Should I Go Webview or Native?

Ionic 2 looks very tempting as someone who is familiar with the Ionic ecosystem. However, after extensively using Ionic 1 (comes with Angular 1) and a custom VueJS + Cordova solution, I am looking forward to trying a native approach in an attempt to avoid some of the pitfalls I experienced with webview-based hybrid applications.

This does not mean that a webview approach is any less effective or appropriate. The right tool should be used for the task at hand. My recommendations:

You should try the webview-based Ionic Framework … if you are looking for a framework that minimizes the difficulty of organizing your code and offers the freedom of using existing web technology.

You should try React Native … if you are looking to have more control over your program design and data flow, with an added performance boost as a nice little perk.