Single codebase – multiple platforms: NativeScript and React Native

Lately we needed to rewrite a project with such framework, which could help us build common codebase for several platforms – web, Android and iOS. Currently, we write nearly the same logic for all three making it more expensive and time-consuming.

So, I had these three days for a research. As a result, we will still continue writing native, however I’d like to share this small research on my blog. If you have used any of them (NativeScript, React Native) in a public project, I’d gladly look at it and listen to recommendations.

Let’s dive in: hybrids were ignored from the beginning. Hybrid is a mobile app, which can written using html/css/javascript and is loaded in our app by web view component. Unlike an ordinary website, it can access API of the mobile OS, but it’s rendered just like a site. Native application is far more smooth and performant, user experience is different, so hybrids are generally used for small apps or prototypes.

There are lots of frameworks to create a hybrid: Cordova (ყოფილი PhoneGap), Ionic, Sencha Touch, Mobile Angular UI, etc.

I could find relatively small number of ones, which does not render a site, but map javascript code with native elements and create, in fact, native applications. For instance,



Telerik, which you may know from their hybrid library, created NativeScript – a framework, with which one can build a native mobile app using Angular, Typescript and JavaScript.

A virtual machine is started on a phone and using reflection, C++ and OS API it creates a bridge to connect to native components. More details can be found on this page: How NativeScript Works
However, despite of this bridge, you won’t notice a performance lag in comparison with a real native app.

Main pros of the framework:
– Native UI
– Extensible (Easily reuse existing plugins from npm, CocoaPods (iOS) and Gradle (Android) directly in NativeScript projects)
– Cross-Platform: Write and deploy native mobile apps for iOS, Android and (soon) Windows from a single code base
– Open source: Apache 2 license.

The learning curve was quite low, too. Recently, they took Angular framework and used the same naming and api, so if you have experience with the latter, it should be easy for you.

Unlike a website, in NativeScript and React Native we don’t create views with html, but with xml, which resembles views in Android.

	<Button ios:text="foo" android:text="bar"></Button>

We can specify different logic for different platforms. Button code above is one of examples. In case of a JS code, we can write if (page.ios) { … }

Part of the design – colors, font size, flex layout – is done with css. Clearly, not all css rules are available, but there are ones which could be mapped with native components.

The reason for my attraction was the possibility of sharing codebase with a web-app. However this turned out not so simple. Large part was still remaining separate. Some parts of javascript code can be shared if you export it as a npm module. (There also is another way, where you unite everything in a single project like this, but in my opinion it added too many if statements and complexity, so I didn’t really like it on the first look).

As far as mobile platforms are concerned, almost all code can be shared here.

To do some experiments, I selected out one relatively complex page and started to build it with this framework. Some things were pretty easy to do, but when I needed a bit more demanding UI, I got stuck. One example was a bottom tab bar of Android, which is currently impossible to use with this NativeScript. Actually, I was a bit skeptical from the beginning, when I saw their showcase. The apps seemed too simple. But this is still a new framework. Probably it will be much better in couple of years.


React Native

This one had a far more impressive gallery. It has been used in thousands of apps. React Native framework comes from Facebook and looks like React. When I tried it out, I definitely agreed to some articles, stating that unlike NativeScript, here you have far more control over the UI, so you are free in your designs, but more control requires more code.

React Native also tries to have a shared codebase, but it still focuses on differences among various platforms. As they say, in case of large apps, you won’t be able to share 100% of code between iOS and Android. Sure, you can use third-party plugins and make them lookalike, but if you ‘respect’ the features of different platforms, you will have to write some code separately.
A simple example would be a date picker, as its visual and ux is radically different on iOS and Android.

React Native tries not to strip off these specific traits of the platforms.
Some people nag about the licence as its published with BSD, however I could not see much constraints.



If I were starting a new project with a complex UI and not rewriting one, probably I would go with React Native. However, it’s not like you will easily start coding the next day. Even for only those few pages I still had to go through lots of trial and error, because of some version compatibility and also the framework was new to me. Android skills go hand-in-hand with both of these frameworks as the process of building UI looks similar.

There is one more – Xamarin, and you need C# here. It was a Windows world, so at this time – not for us. By the way, Xamarin acts a bit differently. E.g. iOS project is directly compiled into assembly. For Android it uses a Mono .Net framework. More details can be found here: Understanding the Xamarin mobile platform

I could not find other similar frameworks. Do you know any?



9 thoughts on “Single codebase – multiple platforms: NativeScript and React Native

  • Friday March 10th, 2017 at 09:40 PM

    არ არის აუცილებელი მთლიანად ReactNative-ში გადაწერა, ერთი view-ით შეგიძლია დაიწყო. ინსტაგრამის მაგალითი დაგეხმარება, თუარ გინახავს:

    • Saturday March 11th, 2017 at 10:19 PM

      მადლობა 🙂 წავიკითხე ახლა ეს სტატია. პლიუსია რომ მიგრაცია შეიძლება ნელნელა, თუმცა თუ სრულად ვაპირებ დამიგრირებას (რადგან ზედ უნდა დაშენდეს ახალი რამეები), მაინც იგივე რესურსი და დრო დაიხარჯება. გამოდის, თან პარალელურად უნდა გაგრძელდეს ნეითივებზე მუშაობა და თან ვიღაცამ react native უნდა ისწავლოს და გადაიტანოს.

  • Sunday March 12th, 2017 at 06:04 PM

    API driven აპლიკაციები რომელშიდაც ძირითადად ფიდებია და მათი ვიზუალიზაცია React Native-ით საკმაოდ კარგები გამოდის. Atrsy-მ ახლახანს გადაიყვანეს თავიანთი აპი (რომელიც ასევე ოფენ სორსია და ჩახედვა შეგიძლია) და საკმაოდ წარმატებით, განსაკუთრებით დეველოპმენტის დროის შემცირების მხრივ. ბლოგზე კარგაფ აქვთ პროცესი აღწერილი.

    მე პირადად ნეითივის მომხრე ვარ, მარა ამ სოციალური აპების წერა ყველაზე ნაკლებად მომწონს. So, I’m not target audience either.


    • Tuesday March 14th, 2017 at 11:05 PM

      მადლობა ტოტო 🙂 წავიკითხავ აუცილებლად

  • Saturday April 1st, 2017 at 04:31 AM

    მიუხედავად იმისა, რომ არ გამომიყენებია არასდროს, ზემოთ ნახსენები პლეადის წარმომადგენელია 😀

    • Saturday April 1st, 2017 at 04:36 AM

      ხო სტატიის ის ნაწილი გამომრჩა სადაც ჰიბრიდებზე საუბრობდი ასე რომ ჩემი კომენტარი უკომენტაროდ დავტოვოთ

      • Saturday April 1st, 2017 at 02:30 PM

        კარგი :))

  • Saturday September 9th, 2017 at 10:17 AM

    რეაქტი/რეაქტ-ნეიტივი ძალიან მომწონს…
    საერთოდ ამათმა აღმოჩენამ ძალიან გამიმარტივა მუშაობა (+რედაქსი).
    კარგია რომ რეაქტ-ნეიტივში სვგ მხარდაჭერაა და დაუშვათ ვისაც გსურთ სვგ გრაფიკების გამოყენება ცხრილებისთვის ყველას გირჩევთ Victory ბიბლიოთეკას…
    იგივე ბიბლიოთეკა რეაქტისთვისაც არის ცალკე.
    იონიკი არ გამომიყენებია მაგრამ ბენჩმარკზე რნ-ს ჩამოუვარდება ბევრი პარამეტრით.

    • Monday November 6th, 2017 at 05:15 PM

      ძალიან კარგი 🙂
      ისე, სახალხოდ ხომ არ დევს რომელიმე შენი პროექტი, რომელშიც რეაქტ-ნეიტივი გამოიყენე?


Leave a Reply

Your email address will not be published. Required fields are marked *