7 Problems With Hybrid Mobile Development And How NativeScript Solves Them

I’ve been a mobile application developer since 2010 and I’ve played around with my fair share technologies and frameworks. While I’ve developed applications that can be safely classified as vanilla native or core native using Java, I’ve spent most of my time developing cross platform applications for Android and iOS using frameworks such as Ionic Framework and NativeScript that support web technologies.

The convenience of cross platform development with web technologies doesn’t come without penalty for certain frameworks. After all, mobile development frameworks can be split into a hybrid web category which act as web applications bundled into a mobile application and a native mobile category which act as web applications compiled into a mobile application. The difference being in my use of bundled vs compiled.

We’re going to see some of the problems that developers face when choosing to use a hybrid development framework such as, but not limited to, Ionic Framework vs a native development framework such as NativeScript.

Going forward, it is important to know that there are other native mobile development frameworks beyond NativeScript. They all accomplish the same task, but using different techniques. I chose NativeScript because I’m a fan of Angular and Vue.js.

Hybrid Mobile Applications are Slow and Inconsistent Across Devices

Hybrid mobile applications exist because of the ability to use the native WebView component for any given mobile platform. Essentially what is happening is the developer builds a web application using their favorite web technologies and it gets bundled into the mobile application binary and served through the native WebView component.

The problem with this approach is that all platforms, whether it be Android, iOS, or other, have slightly different underlying WebView components. Not to mention for any given platform, there are X number of varying quality devices on the market.

Think of it this way. You’ve got your Mac, Linux, or Windows computer and if you’re like me you have at least three different web browsers installed and available. Not all web browsers are equal, so even though I might load my application in Chrome, it doesn’t mean it will perform the same in Firefox. In any scenario, your web browser is serving the application rather than you directly accessing and using it as a native application like say the web browser itself.

All of this leads to slow performing mobile applications, but probably more important in my opinion, inconsistently performing mobile applications.

Now, I get it, there are a lot of people who are going to say that their applications built with a hybrid framework are “fast enough” or “good enough”, but I think that is the wrong mentality to have. User experience (UX) is everything and as a user of a few bad applications out there, I always get a sense the developer doesn’t “care enough”. Don’t be that developer.

Instead, you can move your hybrid mobile applications to a native framework like NativeScript. Instead of using a WebView component, NativeScript maps the UI markup in your code to native components as per Apple and Android had intended. Cut out the middleman WebView component that is known to have strange behavior across the board and you’re going to have a more reliable and faster application.

Does this mean that your application will never be slow with NativeScript? No, because as a developer you could poorly develop your application and even in the best scenario, there will always be users with ancient or budget devices. You will have an edge though when it comes to your application being as fast as it can.

Web UI Components Appear Similar to Native Components at Best

Continuing on the whole WebView vs no WebView angle of the hybrid vs native debate, we have the application appearance. Because hybrid mobile applications do not use native components from within the WebView, they never truly look native.

So what does a native mobile application or what do native components actually look like?

It isn’t an easy question to answer because it is so variable. There are many applications that go above and beyond and make stunning UIs using heavily customized components. To be fair, hybrid and native applications fall into this category. However, most of the applications on my device do not have a heavily customized UI. Every year Apple and Android come up with a new theme in their latest OS release. Remember Material Design a few years back? While it is not impossible to try to model your web components after native looking components, they never seem to actually feel the same or act the same as their native counterpart.

In NativeScript, because you’re using native components, you don’t have to jump through any hoops when it comes to designing your application the way that Apple and Android intended. When a new platform version releases, you’ll already be up to date on the latest theme in your application. This doesn’t mean you shouldn’t design them different, but at the most basic level, they will look and perform great regardless of what platform version you’re using.

Interacting Directly with Native Features is Complicated in a Hybrid Application

When it comes to device features, such as touch id for example, you can’t exactly make use of them strictly via a web application. In these circumstances plugins are available that enable interaction between the web application and native device.

Let’s take Apache Cordova for example. Let’s say that we want to scan barcodes, so we include the phonegap-plugin-barcodescanner plugin into our project like so:

cordova plugin add phonegap-plugin-barcodescanner

According to the documentation, we can scan for barcodes within our Android and iOS mobile application like so:

cordova.plugins.barcodeScanner.scan(successCallback, errorCallback, options);

Nothing above was terribly difficult. The barcode scanner plugin makes use of the device camera and parses the information from any scanned barcode from the list of compatible barcode types defined in the documentation.

It seems like hybrid applications are fine when it comes to native device features, right?

Well, hybrid mobile applications can access native device features without issue as long as there is a plugin that exists. The problem is that there isn’t a plugin for everything and many of the plugins that exist are no longer maintained or functional. You have to either make your own plugin, or drop the feature from your application.

Hybrid applications can only access native device features through plugins and if you have to create your own plugin, they are not easy. There is no way to directly access native functionality directly from the web application.

NativeScript works a little different when it comes to native functionality.

The NativeScript runtime operates on V8 and JavaScriptCore and injects everything iOS and Android for use within an application. This means you can write a JavaScript variation of the native Java and Objective-C that you’d typically find in pure native, but directly in your TypeScript and JavaScript project files.

Take this for example:

let version = NSBundle.mainBundle().objectForInfoDictionaryKey("CFBundleShortVersionString");

The above line, when placed in any NativeScript project file, will get the application version from within an iOS deployment.

Now, many native APIs take more than a single line to include. I once did some pure Android stuff in Java that took around twenty lines. For convenience, NativeScript has a plugin system, like Apache Cordova.

tns plugin add nativescript-barcodescanner

The above command would install the nativescript-barcodescanner plugin, similar to how we did it in Apache Cordova. To use the plugin in a NativeScript application, you could do something like this:

barcodescanner.scan(options).then(result => {}, error => {});

When comparing native functionality between hybrid and native, don’t compare the plugins. For both, plugins are very easy to use. Take a step back and look at what plugins exist, which are maintained, which still work, and if it is possible to directly use native APIs in any given project file. This is where hybrid applications become more complicated than those built with NativeScript.

The Latest Features are not Immediately Available

Every year, Android and Apple make announcements of changes to either platforms in the latest version of their mobile operating system. Whether it be changes around theming, enhancements to existing features, or new features all together, we’ve come to expect something every year as a consumer and as a developer.

For hybrid mobile application development, things are a little (or a lot) slow when it comes to getting new features. As I previously mentioned, you can’t use native APIs directly from your JavaScript and TypeScript files. This means you either need to wait until plugins begin to support your feature, a developer creates a plugin with your feature, or you decide to create a plugin with said feature yourself. The process can take any amount of time from a few days to even a few months.

Putting further emphasis on NativeScript, you’re able to work directly with the native APIs, themes, and components as they become available with absolutely no delay.

App Stores are Cracking Down

Up until recently, app stores like iTunes and Google Play haven’t really cared what kind of applications show up or how they were created. As long as they didn’t explicitly violate a rule, the application could remain available without penalty.

In 2017, things started to shake up with Apple in particular. Apple started to crack down on applications with dynamic content and functionality. Hit hard with this was applications that made use of Rollout.io. On the Rollout.io website, the following statement was shared regarding Apple’s guidelines:

… Apple has been contacting developers with a warning that any framework or “code designed explicitly with the capability to change your app’s behavior or functionality after App Review approval” is no longer in compliance with guidelines.

Fast forward to recently and stories started popping up in regards to other popular applications. For example, Ionic Framework had an application called Ionic View that was recently banned from the App Store. You can read about the official statement from Ionic here.

While Ionic View is a different situation, since it was designed for testing, it begs the question, what’s next? If I had to make a prediction, I’d say Apple will start to define any applications that hold more than a certain percentage of their functionality in a WebView, will be removed from the App Store. Again, it is just a prediction, but it is difficult for Apple to track what happens inside of a WebView.

NativeScript likely won’t suffer from this problem because it doesn’t use a WebView. NativeScript projects are transpiled into native.

Many SDKs only have a Pure Native Offering

When it comes to native device features and APIs, there is a finite number of them. There is a decent chance you’ll be able to find a plugin for the feature you want to use with Apache Cordova and if you don’t want to use native APIs directly, there is a decent chance you’ll find what you need for NativeScript as well.

However, what happens when you need to use a feature or service defined by a third party? There are thousands of companies out there offering an SDK for mobile development and many, if not most, of those companies only offer something for pure Android with Java and pure iOS with Objective-C or Swift.

What do you do when the SDK you need isn’t available for your Apache Cordova based mobile application?

You could ask the company nicely to create an SDK for you, but they’ll likely only do that if there is a demand in paying customers. You could go and create your own plugin for the SDK, but that requires the Android and iOS know-how. You’re kind of stuck at this point as a hybrid mobile application developer.

Going back to previous statements about NativeScript’s ability to use native APIs directly, this is less of an issue. If a NativeScript plugin doesn’t exist for the SDK you want to use, so what? Look at the API documentation for the SDK and write simple JavaScript to use it directly in your native mobile application with NativeScript.

Native Coding Might Still Be in the Equation

I’m singing the same song here when it comes to native features and APIs. If you’re a hybrid mobile application developer and a plugin that you need doesn’t exist, you’re in a tough spot.

If you decide to go write your own plugin for something like Apache Cordova, you’re going to need to have somewhat of an understanding of writing native code.

Here is a source snippet from the popular Toast plugin for Apache Cordova:

- (void)hide:(CDVInvokedUrlCommand*)command {
    [self.webView hideToast];

    CDVPluginResult* pluginResult = [CDVPluginResult resultWithStatus:CDVCommandStatus_OK];
    [self.commandDelegate sendPluginResult:pluginResult callbackId:command.callbackId];
}

The above source is just a small piece of Objective-C code for the iOS side of the plugin. You’d still need to know Java for the Android side. And note that this is not a JavaScript version of the APIs like NativeScript offers.

Many developers try to go into hybrid to get away from native coding, but with hybrid mobile application development, it isn’t entirely possible. With NativeScript, it is.

Conclusion

You just saw seven common problems when it comes to hybrid mobile application development and the reasons why NativeScript is a solid solution to the problems with little to no difference in the development process.

I’ve since switched my development from a hybrid framework to NativeScript because of pretty much all the reasons I’ve listed in this article. I spoke on my story in 2017 and if you’d like to learn more about my presentation, check it out in my article titled, Native to Hybrid and Back Again.

Nic Raboy

Nic Raboy is an advocate of modern web and mobile development technologies. He has experience in C#, JavaScript, Golang and a variety of frameworks such as Angular, NativeScript, and Unity. Nic writes about his development experiences related to making web and mobile development easier to understand.