It has been about 5 years since I’ve done serious mobile development. A lot can, and certainly did, change during this time. With the release of our new mobile app, I decided to re-activate my mobile muscles in anticipation of their deployment. Like many, however, my prior experience was less than ideal. Besides mobile’s laundry list of challenges, I was using one of the worst frameworks known to man. Nevertheless, I took a leap of faith and explored mobile’s current landscape. My hope was rekindled when I discovered NativeScript.
Mobile Development Strategies
To fully appreciate NativeScript, a word should be said about its alternatives. Much has already been written about this. For the sake of completeness, however, I will briefly touch on popular strategies for building mobile applications.
Native
One can say this is the default strategy. For each platform, the developer writes directly against its SDK using a supported language (generally Java for Android and Objective-C or Swift for iOS). The main benefits of this low level approach include: peak performance and direct full feature support. There are no freebies however. To accomplish this strategy, a specific skillset is needed. Also, should support for more than one platform be desired, multiple codebases must be established and somehow kept in sync.
Hybrid
Hybrid mobile development is a goto option for writing once and deploying everywhere. Perhaps the most popular way this is accomplished is by building the “app” within a provided chrome-less web browser. For all intents and purposes, the “app” is technically a web app dressed in a convincing mobile costume. As alluded to, the main benefit here is strong code share-ability between platforms. Keeping iOS and Android in sync becomes a no brainer when they are both running the same code. Also, it is much easier to hire for one, popular skillset (web development) than it is for two.
Despite its strengths, opponents of hybrid mobile development will generally complain about poor performance and lack of unhindered SDK access (i.e. the benefits of native development). Herein lies the power of NativeScript.
Progressive Web App
Before exploring how NativeScript accounts for hybrid’s weaknesses, it is worth mentioning a final, gradually emerging new category: Progressive Web App or PWA. As the name implies, PWAs are actually web apps. In fact, they embrace their identity and make no attempt to show up in mobile app stores. Rather, users access a PWA as they do any other mobile site. The PWA, however, offers helpful mobile-first features such as advanced caching and a dedicated icon for saving to the home screen. The advantages and disadvantages of hybrid can apply to PWA; with added emphasis on a less robust device feature set. Unsurprisingly, PWAs operate within the mercy of mobile browser support. Whereas Google is encouraging them, Apple has been known to lag. To summarize, PWAs are a viable option for enhancing an existing web application’s mobile experience; especially when a full fledged mobile version is not needed.
NativeScript
As the name implies, NativeScript aims to take advantage of native features and performance without forsaking the benefits of hybrid development. Although a grand undertaking, I was impressed with how NS pulls things off.
Native UI
One of the main performance bottlenecks of web-view based hybrid apps comes from the user interface. This is especially apparent on older devices where browser animations and transitions are simply no match for their native counterparts. Also, on a stylistic note, web components will always be web components no matter how much mobile painting they receive. For a genuine mobile experience, a native UI is the way to go.
To accomplish this, NativeScript exposes a familiar, HTML-like API. Here is a snippet from their tutorial:
<StackLayout>
<Image src="res://logo_login"></Image> <TextField hint="Email Address"></TextField>
<TextField hint="Password" secure="true"></TextField>
<Button text="Sign in"></Button>
</StackLayout>
The syntax is very accessible to web developers. To top things off, styling is accomplished via CSS. Thus, after adjusting to NS UI conventions, the average web developer can produce native components without leaving the comfort of “HTML” and CSS.
Direct Native API Access
To access native APIs, a bridge must be formed between the hybrid framework’s language and the device’s. A common way to accomplish this is by creating or leveraging existing plugins. Besides offering this, NativeScript takes things a step further by supporting direct native API access. Borrowing from the linked article, an Android (Java) android.text.format.Time object can be created from JavaScript like so:
var time = new android.text.format.Time();Similarly, an iOS (Objective-C) UIAlertView object like so:
var alert = new UIAlertView();Thus, the native veil has been lifted: web developers can access device APIs in the absence of a relevant plugin.
Is NativeScript for Me?
At this point, the reader may be expecting a final plug: “start using NativeScript today!” or “join us to help make NativeScript even better!”. Rest assured, besides my revolutionary grocery app (and recognizing good technology when I see it), I have no relationship with NativeScript. In fact, here are some reasons not to use it:
Not an Angular Shop
On paper, NativeScript is framework agnostic. In practice, however, its preference for Angular is clear. Thus, I expect the learning curve is lower, and level of support is higher for existing Angular developers. Non-Angular users can still use NS; and I suggest they check it out. They should know, however, that other performant options exist before going full native.
So far, I have presented NS as its own category. The truth, however, is that NS is not the only one or even the first of its kind. Appcelerator’s Titanium has been around for a while; although adoption has been limited. Another option, popular in React circles, is Facebook’s React Native.
Moderate UI Load
As mentioned, a key selling point of native UI elements is that the popular alternative, web views, sacrifice performance. This is generally true but the performance hit may not be obvious for light or moderate UI tasks. Furthermore, mobile web views are getting faster every day. With the help of frameworks such as Ionic, one can build a “good enough” mobile app for most use cases. In fact, the first version of our messaging app has been built in this fashion.
Tight OS Coupling
I presented NativeScript’s elegant exposure of device APIs, one that I have not encountered in other frameworks. Certainly, one can theoretically convert any native app to NS but this is not always the best idea. Consider apps that rely heavily on native APIs or are tightly integrated into the OS. These apps will ultimately have a large amount of platform-specific code: a red flag that this app should be native. The point of hybrid apps is to maximize code share-ability. If, however, one is regularly branching code then this benefit is lost.
I hope this article objectively laid the mobile development landscape and introduced NativeScript as a strong candidate therein. As always, I look forward to starting a discussion below and learning from our readers. Until next time, happy (mobile) coding!