Clients often want their website available in the app store, mostly just for app store presence. I got asked to do app wrapping at work a while ago, because the client purchased a tool that did not have a native app available, only a mob...
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.
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.
Read my post on “Xamarin University: worth it?” to find out more. Getting help from experienced trainers is invaluable.
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.
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#.
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.
Let’s look at the list of good and bad points for NativeScript. Once again the list is not limitative.
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.
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.
NativeScript has been open source since the start on GitHub. So this is something where both Xamarin and NativeScript score points.
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.
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.
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.
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.
|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.
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.