NativeScript vs Xamarin: how to make a choice

Can’t choose between all the mobile application platforms that are available today? Let’s find out if you can make a decision for your personal project or for your team, by comparing two: NativeScript vs Xamarin.

How do you even start making a decision without in depth knowledge of each platform? Both platforms have big companies behind them. Xamarin is backed by Microsoft, where NativeScript is backed by Telerik. In this blogpost I’ll try to give you some insight in each of the technologies and when you should choose one or the other.

My background

I am obliged to say that I am a certified Xamarin developer. But I’m always keeping an eye out for other technologies. So even though I might look biased, I try to make a fair comparison between the 2 platforms. I have been looking into NativeScript as a replacement for Xamarin because I was unhappy with the development flow of Xamarin. I’ll elaborate on that flow later in this blogpost. During the investigation I tried to rebuild an app I was working on. This way I could find out how NativeScript would compare to Xamarin in a real world situation. Let’s get started on the NativeScript vs Xamarin comparison.

By the way, whenever I am referring to Angular, I mean Angular 2 and upwards.

Flavours

Xamarin ‘native’ and Xamarin Forms

There are two flavours to build your apps in Xamarin. Xamarin ‘Native’ as I like to call it, allows you to develop UI’s independently for Android, iOS and/or UWP. This gives you a fair amount of code sharing capabilities, except for the UI. The benefit is that you can have widely varying UI’s on each platform.

Xamarin Forms on the other hand gives you the option to share a lot of your UI code as well. This is especially useful when the UI’s on each platform can look similar. For an elaborate discussion on these 2 flavours, you can read my other blogpost on Xamarin Native vs Xamarin Forms.

NativeScript and NativeScript + Angular

NativeScript has two flavours as well. First off there is regular NativeScript where you use an XML-style UI layer and Javascript code. On the other hand you can use NativeScript in combination with Angular. You use the same XML-style UI layer sprinkled with some Angular goodies. It is advisable to make use of TypeScript in this case, but you could opt for Javascript as well. Some people want to name this Angular Native, to become a bit more competitive in regards of naming with React Native, and just because it’s a mouthful.

In this NativeScript + Angular approach you can reuse most of the code you may have already written for your web-app and just build a new UI on top of that. You get to reuse your already existing services, models and more. This approach is a little harder than regular NativeScript development for newcomers, since it’s yet another layer of abstraction. Personally I found it helpful to first get a grasp on regular NativeScript. Learning what the Angular part adds afterwards gave some great insights.

How does it work?

Xamarin

For Xamarin you use C# to implement your mobile apps. What happens with this C# code depends on the platform you are building for. On iOS this is compiled to ARM assembly language. On Android the same code is compiled to IL and packaged with MonoVM + JIT’ing. The Linker strips out unused code to keep your assemblies as small as possible when you release your app.

Since Xamarin does compile to assemblies, this requires recompilation of your app when you change code. This process can take some time and requires a restart of your app to see changes.

NativeScript

NativeScript uses the Apple JavascriptCore Virtual Machine on iOS and the Google V8 JS Virtual Machine on Android. It uses the NativeScript Runtime to call the required VM methods in order to call native C++ methods on each platform. TJ VanToll gives a perfect explanation and insight in this process in his great blogpost. Knowing how the platform works internally is important if you want to know why certain things are happening.

React Native is the biggest competitor to NativeScript in Javascript land. React Native has its own view on things. A comparison with React Native would take us too far for now.

Pro’s and con’s for Xamarin

Let’s see some of the good and bad points for Xamarin. This list is not limitative and some points are based on my personal opinion (e.g. not backed up with references).

Xamarin – what’s good?

Solid tooling

Microsoft is, in my opinion, known for very good development tooling. Microsoft only acquired Xamarin nearly a year ago on February 24th, so not everything is integrated perfectly yet. Xamarin Studio and Visual Studio are getting more and more aligned. Forms Previewer and other helpful tools have been introduced since and I guess there is a lot more coming.

Open source

Since the acquisition by Microsoft, most of the Xamarin codebase has become open source. This opens up a whole slew of possibilities when you run into a problem. It allows you to fix the issue yourself or at least figure out why something is happening.

Forms Previewer

While this is a good thing, it’s not perfect yet and will not work in all situations. It makes sense this tool still has a ‘Preview’ label. The Forms Previewer does however try to solve a big part of the recompilation hassle and I have big expectations for the future. Having to recompile an entire app for a simple UI change is just annoying.
Gorilla Player is an alternative that has been around a little bit longer but also has its own problems (for example: you can’t use StaticResource for styling and have to fallback on DynamicResource just for this tool).

Lots of plugins available

There are a lot of plugins available on NuGet and you can reuse normal .NET libraries as well. The reason for this is that Xamarin has been around for several years by now and the community is quite big. The most popular plugins are listed in this repository on GitHub. Giving a count is quite hard since there is not a single repository. This can make it hard to discover all available plugins.

Xamarin Test Cloud

Having an option to UI-test your app on a very broad range of devices can give you peace of mind. Xamarin Test Cloud allows you to test your app on over 2000 real devices. Integration with your UI code works seamlessly. Pricing can be high for indie developers, but for companies it’s a justified cost in my opinion.

Xamarin University

Read my post on “Xamarin University: worth it?” to find out more. Getting help from experienced trainers is invaluable.

Xamarin – what’s not so good?

Code recompilation

Whenever you change code, you have to wait for a recompile and restart of your app. This can take a few seconds and gets cumbersome fast. On the simulators/emulators it’s not that bad, but on a real device this cycle seems to take a lot longer. This is the biggest annoyance I have with Xamarin and the very reason I started looking into NativeScript.

Swift/Objective-C compatibility

If you have to integrate iOS code that is originally written in Swift you might have a problem. Building C# bridges for these kind of libraries is a lot harder than it should be in my opinion. First you have to create Objective-C bridging headers, and from there you can use Objective-Sharpie to create a C# bridge. Even then you sometimes still run into problems, making Swift libraries practically unusable. You have to be very proficient in native iOS development to know exactly what you have to do here. The Java part seems to be a lot easier to bridge to C#.

Styling

You can create resource dictionaries with all your styling. But you can only create implicit styles or make them explicit by adding a StaticResource or DynamicResource to the Style attribute of your UI element. You can’t add multiple resources to the Style attribute without creating another explicit style like you can with CSS styling. A nice new option is that you can create reusable themes with the new MergedWith feature of Xamarin. But this doesn’t seem to work flawlessly with the previewer though.

Pro’s and con’s for NativeScript

Let’s look at the list of good and bad points for NativeScript. Once again the list is not limitative.

NativeScript – what’s good?

Instant recompile

No recompilation is necessary because NativeScript uses the Javascript VM’s available on each platform. The tns livesync --watch command makes sure changes are pushed as a new JS bundle to the device. It then automatically refreshes itself in nearly no time. This is especially useful for fast UI development.

Easy to use native code/libraries

Using CocoaPods or Java JARs is fairly easy, since you can just call them in Javascript/Typescript without the need for bridging code. You need to know how to translate Objective-C/Swift and Java to Typescript though. You can transform this into a plugin for reuse by others as well. In any case it’s certainly easier than creating bindings in Xamarin.

Use of CSS

Or SASS for that matter. You can base your app based on a default theme, and use classes on your UI elements just like you would with web development. This makes styling a lot more comprehensible than in Xamarin where you can only use one style “class” on an element.

Open source

NativeScript has been open source since the start on GitHub. So this is something where both Xamarin and NativeScript score points.

NativeScript – what’s not so good?

Platform age

NativeScript has only been around since 29 April 2015, when version 1.0.0 saw the light. A year later version 2.0.0 was released. So it is still fairly new. Since Angular came out of beta, the community around NativeScript started growing, but it still has to prove if it will survive in the future. Too much fragmentation would be bad for adoption. There are even ideas popping up to get Vue.js support in NativeScript, but I have no idea how viable that would be.

Not a lot of plugins yet

Since NativeScript is fairly new, the plugin count is fairly low with 375 listed on NativeScript.rocks at the time of writing. This number includes seeds and other things you can’t really count as a plugin per se. It’s only a matter of time to see this number of plugins increasing though. Now that Angular adoption is rising, things might change quickly in this area.

No easy fallback to native UI

At this moment, there is no possibility to use Storyboards or XIB files on iOS. Sometimes it’s just easier to use Storyboards, but this may be a personal preference as well. Although I haven’t really looked into wearable development with NativeScript, it seems to be possible, but I don’t know which restrictions there are here.

Testing

Telerik is working together with TestDroid to offer a comparable alternative to Xamarin Test Cloud. This service only includes about 400 devices, which is a lot less than Xamarin has to offer. Also the prices seem to be higher. However, if you end up choosing NativeScript you should certainly invest in this for automated UI testing.

How to decide?

Xamarin	NativeScript
You are mainly invested in C#	You are mainly invested in Javascript or Typescript
You want to use Storyboards for iOS	Your focus is on web development
Necessary libraries are available for Xamarin (as a NuGet package)	You want to share Angular parts of a related website
IDE and more visual development tooling is important	You want to use Cocoapods or Swift libraries easily
You want to automatically test on a very broad range of devices	Fast UI development cycle is important
Community size is important *
Need to hire knowledgable consultants *

_{* This is mainly because of platform age}

Whichever platform you choose, it is always wise to have at least one person on your team that is proficient in native platform development for iOS and/or Android. That way you have the ability to incorporate native libraries more easily when they aren’t available as a plugin yet.

If you’re working in a team, using a statically typed language like C# or Typescript (or JS with Flow) is advisable.

Conclusion

Comparing NativeScript vs Xamarin, there is no clear winner that you should always use. Making a choice mainly depends on the skills that are available in your team and the requirements of the app you are building. Keep in mind that there are other options available that might even be more appropriate in your specific case. Except for Xamarin and NativeScript for native app development, you should always consider React Native or real native development as well.

I hope this, rather long, blogpost gave you the necessary insight on how both platforms work, so you can make the right choice for your project.

If you think I made some wrong assumptions or you have a different opinion on something, please leave a comment below.