Building with NativeScript

Here at TapChief, we have been using Angular for the past 6 months. We’ve gotten quite comfortable with it.

As a team of 5 engineers, we’ve set up a REST backend in Django, an ElasticSearch server, and two different Angular products.

Building native applications became a critical business need for us but we didn’t have the resources to build out separate teams for them.

About 3 weeks ago, we decided to jump ahead and use NativeScript so that we could re-use our Angular knowledge and have a shared codebase for iOS and Android. We’ll be sharing our experiences and learning as we continue to build the apps.

Calling Native Android/iOS Code

This is considered NativeScript’s biggest differentiator from Ionic or ReactNative. Think of it as NativeScript having built a language translator which converts your TypeScript code directly into Java/Objective-C code.

We were immediately skeptical that this would be as easy as advertised. So one of the first things we tried was integrating the QuickBlox android and iOS SDKs into our application.

We had to wrap the iOS SDK as a nativescript plugin and create something called a Podfile. This was intimidating since none of us had a clue about iOS development but there was ample documentation for the same. Finally, installing the SDK involved making a folder like this:

The Podfile was just a single line.

# Podfilepod 'QuickBlox'

And the package.json was similarly simple.

# package.json{  "name": "qb-ios-plugin",  "version": "0.0.1",  "nativescript": {    "platforms": {      "ios": "1.3.0"    }  }}

And then running tns build ios.

And then optionally running TNS_TYPESCRIPT_DECLARATIONS_PATH=”$(pwd)/typings” tns build iosto build d.ts files for all typescript code that invokes iOS code.

This is really useful when digging into a new library since it shows you precisely how the TypeScript version of all the methods and classes are referenced — Look at “declare class QMServicesManager” in the code sample below

An example of Typescript code calling native 3rd party iOS SDK code

And here’s a snippet from the auto-generated typings file created for the SDK.

As you can see, it’s very similar to the corresponding native code. You can usually just guess the function names.

NativeScript uses reflection to understand the iOS/Android code and builds typescript bindings for the same. Quickblox.d.ts above is an example of such a binding. What this means is that you don’t have to wait for someone to build out the bridge to obscure third-party packages you want to use. That bridge is automatically created at build-time!

This was much easier than we expected, and it’s incredibly satisfying to hack together a functional chat service integration in a day. Especially when you have never coded Android or iOS before!

TypeScript

Personally, I’m a big fan of static typing. It makes diving into other people’s code much easier. Our own Angular codebase is a lot more maintainable for the same.

And if I couldn’t generate the typings for the iOS library I used above, methods would have been much harder to discover.

TypeScript code ends up looking very similar to the Java code it is actually calling for native bridge calls. Language constructs frequently map together in similar ways and it feels natural to be using TypeScript here.

Build time

I use a MacBook 2016 (16GB Ram, SSD) at work. The first cycle to build the APK from scratch and load it on the phone takes about a minute.

Subsequent incremental builds are a breeze. They only take a few seconds only. Somehow LiveSync for NativeScript is faster than the incremental compilation Angular provides for the web!

Some of my colleagues were using 4-year-old personal laptops with 8GB of RAM and a hard disk. That made builds excruciatingly slow. Each android build would take about 15 minutes from scratch, although the LiveSync (incremental builds) was still only a few seconds long. Those went out the door and everyone has shiny new 16 GB machines with SSDs now :)

Templatization

Deepak, our front-end lead, has written most of our UI components. I’ll have push and prod him to write his own piece later. From my vantage point, it took him about 3–4 days to grok the documentation on UI and a full week of painfully and slowly writing templates. But beyond this, he was nearly as productive as with HTML in Angular.

While the XML code is the same in most places, there are small bits and pieces of Android or iOS-only logic which sneak into the template files.

SCSS has been instrumental in structuring our styling in our Angular code-base and being able to use SCSS and all the conventions we picked up there has made our job a lot easier here.

Learning curve

It took a while to learn the XML based template language. And as someone who’s never made an iOS app, I had to learn about delegates, installing libraries and other minor quirks. With android too, writing a plugin the first time took some work.

But otherwise, virtually everything else is the same as it is for Angular. We just skimmed through the tutorials and dived right into coding. If you’ve had prior experience with Angular, it should be a very easy transition — a week or two before you feel productive.

Service logic written in Angular was copy-pasted nearly as is for the NativeScript code base. UI Components are being written pretty much from scratch though. Deepak has been focussed on writing UI components while Abhijith and I have been figuring out how to integrate chat, google-places, native plugins, writing a rich-text editor and more. Only 3 of the 5 of us are working on the NativeScript application and we’re seeing good progress.

Documentation has been decent. And between that and some googling, we haven’t had to reach out to the community directly (yet) to sort out our issues.

We’re having a good time with NativeScript. It feels borderline magical at times. There’s the question that has a lot of the community abuzz. Would Airbnb have had the same issues with NativeScript? — Airbnb sunsets ReactNative

Two of their biggest issues were1. Lack of typing in Javascript2. Native bridges to the underlying platforms were excruciating to build

These are both inherent strengths of NativeScript. My own experiences have been limited but I’d wager they’d have had a better experience with NativeScript.

Building with NativeScript was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.