What NativeScript Means to Mobile Development

Many moons ago we were in the pre-iPhone era. For those of you reading this who remember, we were carrying around our Windows 6 mobile phones and geeking out over the latest Samsung Blackjack. There were fewer platforms and devices back then. Nowadays, new devices come out monthly. The increasingly frequent rate that devices are released has driven the development community to look for ways to write different types of mobile apps.

Different Types of Mobile Apps

In today’s world, mobile apps fall into one of four major categories: native; hybrid; cross-compiled; and just-in-time (JIT) compiled (table 1).

Table 1 Different mobile app types and their popular frameworks

Mobile App Type	Framework
native	Android, iOS
hybrid	PhoneGap/Cordova
cross-compiled	Xamarin
JIT compiled	NativeScript

DEFINITION: Just-in-time (JIT) compiled apps are apps that are compiled at runtime versus being compiled before the execution of the app. For example, in a just-in-time app, your source code isn’t compiled to native machine code until the absolute last minute, or immediately prior to executing each statement.

Excluding native apps, the other three app types in table 1 work towards the same goal of writing your app code once and deploying it to multiple platforms (which is what people mean when they say cross-platform). Although these devices try to achieve similar results, each mobile app type in table 1 reaches the goal utilizing a different route.

Figure 1 How different types of mobile apps run on a device

In figure 1, you can see that each type of mobile app uses a different mechanism to run on a mobile device. Hybrid mobile apps are webpages that are loaded and run by a container app within the framework that runs on the device. Because hybrid apps are webpages running inside of a container app, some device functionality may not be accessible to your app. A cross-compiled mobile app is run through a compiler first, and then compiled into a native app that runs on a device. Because these apps are compiled, the latest features and updates may not be accessible to you on immediate release. Lastly, JIT compiled apps, such as ones written in NativeScript, run natively on the device inside of the device’s JavaScript virtual machine.

DEFINITION: A JavaScript virtual machine is a piece of software that runs JavaScript code.

If you’re a .NET or Java developer, running code in a virtual machine will be familiar because both frameworks run their code in a virtualized manner. When the code in a JIT compiled app is run by a virtual machine on a device, you’ve access to all native hardware, features, and updates that the latest version of the device’s operating system may have released.

Why NativeScript is Important

Besides JIT compilation, NativeScript has many other differences from other mobile app frameworks. You’ll soon come to find out that these differences are what make NativeScript important in our minds.

NativeScript offers a truly write-once, deploy-everywhere framework. In my experience working with other frameworks, there’s a lot of “shim” code that needs to be written. This code acts like a piece of wood used to help frame a doorway. In most cases the doorway will fit perfectly, but sometimes we need to add a little here and a little there to get it to fit and work right. When writing code, you may need to add a bit of UI code to make a button display correctly in the Android version of the app. Likewise, you may need to write additional UI code to make the dropdown box look right in the iOS app.

Figure 2 NativeScript – write-once, deploy-everywhere

Figure 2 illustrates the example of the shim code. Other frameworks may require specific Android or iOS code be written for your app. NativeScript view code (and non-view code) is written one time and translates to a native experience on whatever platform you’re targeting and running your app on, which means you don’t need to write shim code. Even though you don’t have to write shim code in NativeScript apps, you can still write a fully-customized app using native features and hardware.

As we dig deeper into NativeScript, we’ll introduce you to the structured approach that NativeScript requires to create an app. This convention-based approach to creating apps also helps to set NativeScript apart from other frameworks.

 What types of apps can be built with NativeScript?

Now that we know a bit more about what NativeScript means for you, it’s time to take a look at what kind of apps you can write with it. Remember that your NativeScript app is running directly on, and being interpreted by, the device’s JavaScript virtual machine. This means that you can write any kind of app, because you have access to anything the mobile device can do! Let’s look at the types of apps NativeScript is best suited to build.

Let’s first start with a type of app that NativeScript wouldn’t be ideal for. Imagine that you’re developing the next big mobile game – Floppy Bunny. The game requires extremely high performance to render intense 3d graphics. NativeScript is performant out of the box, but it isn’t the best choice for creating a graphic-intensive game. NativeScript runs inside of the device’s JavaScript virtual machine, and there’s an extra, albeit small, layer of abstraction between you and the bare metal. To extract every bit of performance out of the device to make Floppy Bunny an overwhelming success you should consider writing a native Android or iOS app.

If you’re feeling down because I shattered your Floppy Bunny idea, don’t worry, there are other types of apps that NativeScript is great for! Unlike our game example, NativeScript is a perfect choice if you’re developing a business to consumer app such as a news feed, a companion app for a website, a social media app, or even an app to control all the smart devices in your home!

NativeScript’s truly write-once and deploy-everywhere nature helps you if you’re racing to become first to market with a brand new app idea. Suppose you work on small team that has a web development background. Because of the similarities to HTML, JavaScript, and CSS, NativeScript would be a great choice for your team to use to implement their first mobile app. In this case, NativeScript could help reduce the turnaround time to release your app and allow your company to reach the largest possible market, all while maintaining a single code base!

How NativeScript Works

Writing native mobile apps using JavaScript, XML, and CSS isn’t something that you commonly hear about; instead, you hear about writing native mobile apps in Objective C, Swift, or Java. NativeScript makes it possible to write native mobile apps with several components: the NativeScript runtime; core modules; JavaScript virtual machines; your app code; and the NativeScript command line interface (CLI). Figure 3 shows how these components work together to create native Android and iOS projects, which get built into native apps that run on a mobile device.

Figure 3 How NativeScript components and your app code work together to build and run native iOS and Android apps

I know there are a lot of boxes and lines in figure 3, and visualizing how these components work together may seem overwhelming. Don’t worry, it’s easier than it looks. You’ve already learned that you write your app code in JavaScript, CSS, and XML. Your code then interacts with the NativeScript Runtime and the NativeScript Code Modules, but when writing your code, you don’t even notice these interactions. The NativeScript CLI bundles these components together with a JavaScript virtual machine into a native app that runs on a mobile device.

You’ve learned how NativeScript apps work at a 10,000-foot level, but let’s dive deeper. After creating your user interface (UI) using XML, you use CSS to style the UI (like the way CSS is used to style HTML apps). JavaScript is used to augment your UI, by writing business logic code to respond to events (i.e. when your app starts up) and interactions (i.e. you tap a button). These three pieces (UI written with XML, CSS, and business logic written with JavaScript) combine to create your app code.

By itself, your app code doesn’t have everything it needs to run on a mobile device – you also need the help of three additional components: the NativeScript runtime; core modules; and a JavaScript virtual machine. Your app code and these three components form the core of your NativeScript app.

Once you’ve developed your app code, the app core is fed into the NativeScript command line interface (CLI). The CLI is responsible for creating native Android and iOS projects and merging the NativeScript app core into them. The CLI invokes native software development kits (SDKs) to build and compile the native app projects (which include your app’s NativeScript core) into a native app. The compiled app is deployed by the CLI and run on a physical device, simulator, or emulator.

As you can see, NativeScript’s beauty lies in its simplicity. When you’re developing cross-platform apps, you don’t have to spend time learning native programming languages like Objective C, Swift, and Java, because you can just use JavaScript. Furthermore because of the platform-agnostic commands provided by the NativeScript CLI, you don’t need to learn how the native tools and SDKs for Android and iOS work to build and deploy your app.

Try NativeScript for yourself!

If you’re a JavaScript developer who is interested in cross-platform app development, without having to learn a new language first, then NativeScript might just be what you’re looking for. Learn to leverage your JavaScript skill set in a major way, and start writing native apps for all platforms. The beauty of it is – you don’t even have to learn native code! NativeScript in Action is here to show you how it all works so go ahead and have a look – you won’t regret it!

Download the free first chapter of NativeScript in Action and see what NativeScript can do for you.

For more information (and a discount code) also see this Slideshare presentation.