NativeScript for .NET Developers

Contrary to what it may sound like, NativeScript is not a programming language – in fact, it simply uses languages you may already know: JavaScript, CSS and XML. NativeScript is a framework for building cross-platform truly native mobile apps with JavaScript!

There is no DOM, no cross-compilation and no hybrid mobile WebView rendering. You have a single codebase of JavaScript, XML and CSS towards making a native app that runs cross-platform. NativeScript as a platform is open source, and offers free developer tooling via the Command Line Interface (CLI).

Now, it may sound like NativeScript is mostly catering to JavaScript developers – you know, those skinny jeans hipsters, so to speak. While you may respect non-Microsoft developers, perhaps you are not one of them. Maybe you are a .NET developer on the Microsoft stack and rather proud of it. If so, you’d have good reason – it is one of the richest possible developer ecosystems and with some of the best tooling available.

It turns out, NativeScript has lots and lots of appeal for .NET developers. You’re going to enjoy the possibilities. Let’s dive in.

This article is Part I of unpacking NativeScript for .NET developers. In Part II, we’ll talk about UI composition and more tooling.

Visual Studio Familiarity

Now free CLI tooling may be hip, but you probably spend your entire days in Visual Studio. With a paid Telerik Platform subscription (or a free trial), you can build entire NativeScript apps inside of Visual Studio, without ever having to leave the comforts of your favorite IDE.

There are three primary components of a NativeScript app – business logic in JavaScript, UI markup in XML and styling through CSS. And Visual Studio is exceptionally good at supporting JavaScript, XML and CSS – the fit is natural.

Simply sign up or sign in to and click on Getting Started, then Downloads. Pick AppBuilder NativeScript and download/install the AppBuilder Extension for Visual Studio. You are all set.

Build your NativeScript app in VS

When you do File > New Project, you’ll see all the NativeScript project templates.


Once you create a NativeScript project in Visual Studio, you are greeted with a project structure that may seem familiar. All of the NativeScript Modules reside in a single tns_modules folder, App_Resources houses your platform-specific icons and app folder contains all your code.

You may notice simple MVVM-type conventions – if you have a main-page.xml (UI markup), NativeScript will automatically pair it with a main-page.js (code-behind) and it is customary to have a main-view-model.js (view model) in the same folder.


Once inside of Visual Studio, you’ll get all the usual help for writing code in JavaScript, XML and CSS, such as syntax highlighting and code completion.



Need to bring in some package dependencies? As expected, you get Visual Studio intellisense in package.json edits, as below:


NativeScript gives you access to all of the native platform APIs. You also get robust app life cycle management control including the following application life cycle events – launch, suspend, resume, exit, lowMemory and uncaughtError. At any point, you can persist and restore application settings – with direct device file system access through the application-settings NativeScript module.

Almost anything you can do on a native app, you can do so through NativeScript modules and abstractions – only via a single codebase that serves multiple platforms.

Deploy your NativeScript app from VS

Once you are ready to try out your NativeScript app, use the Visual Studio AppBuilder menu. You can run your project on native emulators or directly on devices.


If you are deploying to emulators, you can choose to run your Android project on the native Android emulator or the GenyMotion one or even the Microsoft-made Android emulator. For deploying iOS apps to a native emulator from Visual Studio, you have to have a remote OSX machine configured as a build host.


It’s important to state, however, that you don’t have to have a Mac to build for iOS! You can simply choose to use your existing iOS devices and deploy directly to them. If you are an existing Telerik Platform subscriber, simply utilize the cloud iOS/Android builds. You can build your app as a native app package or deploy it through the corresponding NativeScript Companion apps, available on each platform.


The cloud builds produce a simple QR code with a link to your app package, with all your code and assets included. Convenient, right? And yes, you can share this QR code with your app testers.

Once installed, you don’t have to keep deploying the whole app package for every code change. Simply tap and hold with three fingers on the app – the latest bits get pulled down to your device through a feature called LiveSync.


So, how do you scan the QR codes from your device? Sure you can use any QR code scanner, but the NativeScript Companion app actually has one built-in. Simply swipe with two fingers from the left edge, as below.


Once you scan a QR code, the app package gets pulled down and deployed inside the NativeScript Companion app shell, as you can see in the screenshot below that loaded the default Hello World app.



JavaScript Against a Common API Canvas

NativeScript Modules offer access to the native platform APIs. You can write plain JavaScript to call the APIs on either platform.

NativeScript uses the popular CommonJS module format, allowing you to simply require whichever NativeScript module you need. All device, platform or user interface functionalities reside in separate modules.

For example, the code sample below shows how you can use the camera to take a picture – NativeScript handles communicating this to the corresponding native API calls.

var cameraModule = require("camera");
var imageModule = require("ui/image");
cameraModule.takePicture().then(function(picture) {
    console.log("Result is an image source instance");
    var image = new imageModule.Image();
    image.imageSource = picture;

Business Logic in TypeScript

Now straight up JavaScript may not be your comfort zone. .NET developers often like their type safety in object oriented programming and are not fond of some of the “weirdness” that a dynamic language like JavaScript brings to the table.

Thankfully, if you are a .NET developer, there is a better choice for you. You can write your app business logic code entirely in TypeScript!

If you come from a C# background, you’ll feel right at home in TypeScript, which has been enjoying a lot of love lately. TypeScript has the typical object-oriented programming paradigms like classes, interfaces, access modifiers and extensions.

And sometimes, the small things make all the difference, like in the TypeScript syntax as shown in some examples below.

// Inferred types from assignment.
var a = 5;

// Arrays can be typed.
var array : number[] = [];
// This triggers an editor warning.
array[1]="Hello World";

// OOP with confidence, without the dynamic randomness.
class Auto{
var car = new Auto();
car.wheels = 2;
car.doors = 4;
// This triggers an editor warning.
car.gears = 6;

Here’s how you write TypeScript code in your NativeScript apps to get the device geolocation.

import locationModule = require("location");
var locationManager = new locationModule.LocationManager();
var locationOptions = {
    desiredAccuracy: 3,
    updateDistance: 0,
    minimumUpdateTime: 5000,
    maximumAge: 20000
    console.log("Location received: " + location);
    }, function (error) {
        console.log("Location error received: " + error);
    }, locationOptions);

Grab your favorite code editor, like Visual Studio or Visual Studio Code and use them to write TypeScript for your NativeScript mobile apps. You also get NativeScript Definition Files (the *.d.ts files in the NativeScript repo) that surface some of the native API metadata to give you code completion features – TypeScript intellisense for iOS/Android just makes your coding so much easier.



The NativeScript promise is simple – you can build truly native cross-platform apps with a single codebase of JavaScript, XML and CSS. NativeScript offers plenty of tooling for the Visual Studio developer – everything from building the app, to testing and deployment. Don’t like JavaScript? Fine, you get to write your app business logic with TypeScript. Choice for developers is a good thing, and .NET developers get plenty of love in NativeScript.


  • Pingback: Dew Drop – September 10, 2015 (#2087) | Morning Dew()

  • So I’ll be the one to ask about the pink elephant in the room.

    Why would .NET developers want to use javascript over nativescript when they could use C# over xamarin?

    • Samidip Basu

      @dotnetchris:disqus It’s not an either/or .. all about choices for developers. If you swear by C#, by all means – go with Xamarin. You’ll see we partner closely with Xamarin to make polished UI controls available. But if JavaScript or TypeScript is your thing, NativeScript is a great choice to go cross-platform native! And you still don’t need a glowing fruit 🙂 Hope this helps.

      • maybe the title would have been more accurate as “for Visual Studio coders” or “developers who use Visual Studio” but i concede that is less attention grabbing in a title than “.NET developers”

        • remotesynth

          Heh. Funny you mention as that was an editorial change I made – the original title was what you mentioned but I changed it since many of the benefits were not specific to Visual Studio. Nonetheless, I think part 2, which is already in the queue, can feel comfortable with NativeScript’s tooling and conventions.

          All that being said, there are benefits to choosing NativeScript that I might think could convince a .Net developer (or any developer for that matter) to choose it. Two important differences with Xamarin might be that it’s not cross-compiled, which makes very cool features like LiveSync possible and it’s open source (and free to use if you are comfortable working with the command line tooling).

    • Valentin Stoychev

      @dotnetchris:disqus TypeScript is very similar to C#. If the language choice was stopping you to look at anything else than Xamarin I think now you have a good reason to evaluate the NativeScript framework, look at its programming model, do some proof of concept and decide if you like it more than Xamarin or not.

      I think as a start it is worth looking at the speed the NativeScript framework is moving by looking at the community -created issues @ GitHub and how they are implemented/supported –

      Feel free to send any questions here or on GitHub, where all the magic happens :).

  • Pingback: Update Visual Studio 2015 to fix devenv process freezing()

  • Pingback: Building NativeScript UI for .NET Developers -Telerik Developer Network()

  • Pingback: Building NativeScript UI for .NET Developers | Ramblings of a Modern Developer()