NativeScript – a Technical Overview

I am really excited to be part of the engineering team behind Telerik’s new endeavor – NativeScript. It is something so big, challenging and inspiring for me that I can’t wait to share with you a brief overview from a more technical perspective. If you still haven’t read the the announcement, please do so before reading this post, just to ensure you have the overall picture.

So, what is NativeScript?

Well, it is not only a set of libraries but rather a runtime that enables you to call APIs in the Android and iOS (and Windows Universal in the near future) frameworks using JavaScript code. It is built upon several major parts including a JavaScript virtual machine to interpret and execute the JavaScript code as well as what we call “bridge” to translate the calls to the underlying platform-specific APIs. The “bridge” module itself includes a marshaling service that handles data transfer to/from JavaScript to/from native types as well as a set of bindings knowing how to project a certain JavaScript method to its corresponding native equivalent. The JavaScript Virtual Machines are Google’s V8 for Android and WebKit’s JavaScriptCore implementation distributed with iOS 7.0+.

Let’s consider the following code snippet:

var file = new;

The actions that happen here are:

  • The JavaScript VM evaluates the code.
  • The Bindings will determine the corresponding native method to call.
  • The Marshaling service will convert the JavaScript String to a java.lang.String object.
  • The result of the function call will be a custom JavaScript Object serving as a proxy to the native object created on the Android side. When a method is called on this proxy it is delegated to the underlying native object instance.

This mechanism enables you to build full-blown native applications using simple JavaScript code. Additionally, you have all the power, flexibility and extensibility of JavaScript to build your business (platform agnostic) logic – such as data models, data access, view models/controllers, etc. This business logic will be one and the same regardless of the targeted platform.

The following diagrams illustrate the execution flow in greater detail:



You can find more details about NativeScript for Android in this post.

How Do NativeScript Apps Differ from Hybrid Apps?

This is the immediate question that typically follows. The major differences between these two types of apps are the UI Stack and User Input.


  • User Interfaces are created and styled through HTML and CSS. An instance of the platform-specific browser is embedded within the application and is used to visualize the HTML and CSS.
  • The Cordova (PhoneGap) plugins are used to provide access to some of the native APIs in the underlying platform.
  • User Input is handled by the embedded browser instance and delegated further as JavaScript events to the currently focused DOM element.


  • User Interfaces are instances of the corresponding native widgets/visuals – e.g. android.widget.Button or UIKit.UIButton.
  • The NativeScript Runtime provides full access to the underlying native APIs such as Camera, Location, File System, etc.
  • User Input is handled by native handlers (delegates) declared in JavaScript – e.g. View.OnClickListener or UIControl.addTarget implementations.

I’m not suggesting one or the other approach is generally better. They serve different scenarios and solve different problems. We have compiled a list with frequently asked questions which can provide some additional information about what problems NativeScript solves.


The next question I typically receive is about the performance of NativeScript and how it compares to purely native applications implemented in Android or iOS. Well, every additional layer of abstraction comes at a price. The JavaScript code interpretation and data marshaling add their own cost. Our rough measurements show about 10% performance penalty versus the same functionality implemented in native code directly. Still, in most scenarios this 10% is hardly noticeable by the user. Additionally, we’re working on ideas for how the performance can be further optimized and some of these experiments may be included in future versions of the framework.

Modules and Require Support

As a complete Runtime, NativeScript supports JavaScript modules and the implementation follows the CommonJS specification. This feature allows only the JavaScript needed for the current state of the application to be loaded. Later on, as the user interacts with the application, various modules may be loaded if required. For example this very simple snippet shows how to create a stand-alone module, named “about” and representing a new Android Activity:

var activityBody = {
	onCreate: function (bundle) {
    	var relativeLayout = new android.widget.RelativeLayout(this);
exports.activity = com.tns.NativeScriptActivity.extends(activityBody);

The above module can be required as follows:

var activity = require("about").activity;

Built-in NativeScript Modules (NSM)


Accessing native APIs directly from JavaScript is cool but this means you should have a deep knowledge of the underlying Android and iOS APIs in order to know what to call and when. One of our major goals is to provide set of modules and APIs that provide platform-agnostic access to the underlying target platform. For example let’s consider downloading JSON from the internet – you will need some HTTP-access APIs and these APIs are different on each platform.  Our “http” module provides common APIs that you can use without caring about the native APIs:

var http = require("http");
	.then(function (result) {
    		// result is JSON Object

The implementation that lies behind this function is different for each platform, but it is the module that takes care of the specific implementation. This way you can write code once and execute it on each of the supported platforms.

Here is a list of the currently available modules:

  • Application
    Provides an abstraction over the specific native Application objects and exposes common events for the application lifecycle.
  • Console
    Enables various output functions to the console of the development IDE. There is a console object available in the global context for easier access.
  • File System
    Provides access over the file system of the currently targeted platform.
  • Http
    Provides access to http web requests and exposes shortcut functions like getImage, getJSON, etc.
  • Image Source
    Provides an abstraction over the raw image data objects used by the native frameworks.
  • Local Settings
    Provides an abstraction over the shared preferences per application.
  • Location
    Provides an abstraction over the geo-location access APIs.
  • Timer
    Provides well-known JavaScript functions like setTimeout and setInterval. These function are available in the global context directly.

What comes next?

The currently available version is an early preview meant to validate with you – our users – the vision we have and get feedback on how to further shape it. We have numerous ideas in our heads about various features that will enable high productivity with less development hassle. Some of these ideas are:

  • A complete set of UI Stack modules (much like the Core ones), allowing for one codebase deployed to every platform.
  • XML-based UI declarations through code.
  • A visual designer, providing WYSIWYG experience for building UX.
  • A common styling mechanism.
  • The ability to use third-party native libraries.
  • See the roadmap for the complete list.

If we already have your attention, do not hesitate to request your access to these early bits and to share your feedback with us – we are truly hoping to receive as many of your thoughts as possible to ensure a product you will love.

Here are some resource that will help you get started with NativeScript today:

Getting Started