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.
Webview-Based Hybrid Applications
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.
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
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.