Does React Native or NativeScript really work as they claim to be? After all smooth, cross-platform experience is the dream of every developer and business owner since the release of modern smartphones. In the history of mobile we’ve had iPhones and Blackberries, Android, Windows Phones, and a handful of smaller players. Building a native app for each one of these platforms sounds like an expensive venture and a long and arduous process. 

Cta image

Even now, with only two major players left on the market, building a single codebase for iOS, Android, and the web (as some of the solutions allow that) is still a dream that many would like to see brought to reality.

Proponents of native solutions claim that the cross-platform approach is more faulty, provides an inferior experience, and could never replace apps written with Objective-C and Swift for iOS, and Java and Kotlin for Android. Well, if you choose the right tools, these claims are no longer valid and the notion of abandoning the idea of native development makes perfect sense for businesses of all sizes.

Last Friday, on the (literally) big stage of the Vue.js Amsterdam conference, our friends from NativeScript announced the release of NativeScript-Vue 1.0, which allows for building apps for iOS and Android using Vue.js. As we love, use, and support Vue.js we couldn’t just not mention this great accomplishment of the Progress team.

Personally, the announcement brought me back to thinking about cross-platform solutions. Our team is already using some of them for mobile projects, however, there are other players on the cross-platform market that are definitely worth investigating.

In the piece below, I outlined the most popular or interesting approaches to cross-platform development with recommendations on when to use them (with great help from my friend—Szymon Korzeniowski. If you’re considering using such an approach in your product, read on. 


cross-platform development platforms

React Native

React Native logo

Here, the business logic is written in JavaScript and executed in the native JS engine, whereas layout and styles are compiled to native iOS/Android UI elements, providing superior performance to browser-dependent solutions. Therefore, while the business logic can be shared between Web and mobile, layout and styling need to be implemented separately for the Web using HTML and CSS.

React Native is a battle-tested solution already adopted by Skype, Instagram, Airbnb, and Uber.

It revolutionized mobile development by being able to deploy to two platforms at once. Its primary objective is to “Learn once, write anything.” What does it mean exactly? That you get a native look and feel for both iOS and Android, but you may include platform-specific modules: status bars, navigation, or access to native elements like camera and contacts are built according to the platform. Some of those features are available in apt packages, but some will need to be written from scratch.

The question is: can you use React Native for a Web version of either an iOS or an Android app? With solutions like React Native For Web and ReactXP it actually is possible. Both of them build upon React and React Native, aiming to provide equivalents of React Native components for “regular” (i.e. browser-based) React.

Just FYI, of the two, our team prefers ReactXP and here's why.

When should you consider React Native?

Definitely when you’re already using React for the project. Also, if you need a truly native look and feel of all versions of your app.

Roadmap 2019 

As you may have read in the State of React 2018, React has been undergoing some deep internal changes this year, announced by Sophie Alpert, Engineering Manager on React at Facebook:

We're working on a large-scale rearchitecture of React Native to make the framework more flexible and integrate better with native infrastructure in hybrid JavaScript/native apps.

And they didn't stop there. Let's have a look at some plans for RN in open source to happen throughout the next year, and ways to achieve them:

  • Lean core. Due to removing non-core and unused components, the surface area of React Native will be reduced and easier to contribute to. 
  • Updated Internal Tooling. As Facebook team's work differs from development in open source, the RN team plans to introduce unified internal tools. They will also tackle bringing own JavaScript VMs, supporting 64-bit libraries on Android and improving support for a few systems. 
  • Testing infrastructure. They will run internal test to see ensure that Facebook experience with RN is as close to open source as possible. As a result, we'll be able to merge pull requests quicker and we'll get better testing of the core repo on GitHub. 
  • Public API. The team has started converting internal call sites to enable Facebook consume React Native via the public API and reduce unintentional breaking changes.
  • Communication. Increased transparency and open discussion on GitHub is supposed to unify communication among all contributors. The team is also planning to improve user experience by creating quality content and turning to auto-generated API reference docs.

The overall vision embraces building a healthy GitHub repository, achieving stable APIs, creating a vibrant eco-system enhanced by excellent documentation. 


NativeScript logo

NativeScript is an open-source project that helps build native apps with Angular, TypeScript, JavaScript, and now also with Vue.js. NativeScript works similarly to React Native and allows the simultaneous deployment of completely native iOS and Android apps. Additionally, it offers a range of frameworks you can select for development.

NativeScript boasts a different approach than React. Remember the “Learn once, write anything” motto of RN? NS says “Write it once, run it anywhere.” That means it attempts to manage the UI in a transparent and repeatable way between the multiple platforms it supports. NativeScript’s authors want to provide a singular development experience for each platform which is a perfect solution for relatively generic database-powered apps.

As I mentioned before, the NativeScript-Vue integration is now in 1.0 which is a great reason to try it out if you use Vue.js in your stack. According to the general mastermind behind the integration, Igor Randjelovic: “The initial work took a few days, and the Weex implementation (a similar solution for native mobile applications developed by Alibaba) was a tremendous help for figuring out the way to set things up. Another great resource was the NativeScript-Angular implementation which helped me better understand the NativeScript side of things.” The NS team are already planning the next steps for the integration and invites everyone to check out their playground.

When should you consider NativeScript?

If you use Vue.js or Angular and if you need a truly cross-platform app for iOS and Android with a single codebase, NS is the right framework. 

Roadmap for 2019

Concerned whether NativeScript will still be a thing in 2019? Fret not, it will. And it will develop in the direction that we can't wait to see because Nativescript-Vue will become officially supported as a part of the core NativeScript framework in early 2019.

Here are some other plans for NativeScript neatly presented by Veselina Radeva, Product Manager at NativeScript:

The team will continue working on improving the developer experience with HMR and Webpack with the goal for Webpack to become the only way to develop with NativeScript. We already showed that development with Webpack enables HMR, provides better build times of the app during development, and optimizes the app in terms of startup time (...) so we expect it to be a huge win for all the {N} lovers out there.

What else is on the NativeScript's plate for the next 12 months? You can expect enabling code-sharing between Web and Mobile, a very experimental idea called nativescript-web, improving analytics and Crashlytics services, and achieving a rich, beautiful UI. Keen on the details? Read the official NativeScript roadmap. 

Progressive Web Apps (PWA)

unofficial PWA logo

A more lightweight alternative to Hybrid Apps—these are also regular Web apps, but instead of relying on third-party platforms and plug-ins for access to native features, they make use of modern browser APIs.

The thing about PWA is that those apps are not visible in app stores, so choosing this approach will lose you this specific traffic channel. On the other hand, PWA doesn’t leave the Web, so you can easily share it via URL. Quoting Alex Russell: these apps are just websites that took all the right vitamins. As a result, you get a highly performative Web-mobile hybrid—adjusted to all kinds of devices, fast, and installable. It can also be accessed offline and is capable of sending push notifications.

These apps deliver a better user experience and are a great alternative if your website is accessed frequently via mobile devices. The second (or third, or fourth) time a visitor enters your website, they receive a prompt suggesting they add the website to their home screen. Then it looks just like an app.

Support for PWA is currently strongest on Android/Chrome, while the iOS/Safari user experience is still sub-par. Apple is currently working on implementing support of certain PWA features in their ecosystem, however so far there have been reports of less-than-ideal implementation on Apple's side.

When should you consider PWA

If you run a frequently visited website like a news or e-commerce platform, event website, or education-oriented portal. But, to be completely honest, whenever you need a fast and performative website with great UX - which is pretty much always. To give the whole picture, we prepared a complete guide on PWA. 

Hybrid Apps (e.g. Ionic)

Ionic logo

These allow the sharing of not only the business logic (JavaScript) between Web and mobile, but also the layout (HTML) and styling (CSS). Since a hybrid app is essentially a Web app wrapped in a mobile browser runtime with native plugins, there is always some performance overhead—on modern devices, however, the overhead gets less and less noticeable.

As the Web was originally built for Web pages and not complex modern apps, hybrids will never work as smoothly as a native app does. Their performance is not such a bottleneck as a few years ago though. Yet, you must note that if you decide to choose this approach, you will inherit all the problems that come with Web, such as bugs that show up only in specific browsers and devices or styles behaving differently depending on where they’re used.

The biggest issue with hybrid apps right now is their UX. Your app offers the same features for both Web and mobile versions and you actually don’t take advantage of so-called mobile moments—the moments wherein a user accesses their phone to get what they want, in the right context (i.e. a timetable of trains while you’re reaching a train station).

So why should you even consider them, you ask? Well, they’re time- and cost-effective. There are a lot of businesses that actually embrace that. Hybrids will work just fine on modern devices, so if you know that your target group uses new mobiles, maybe this is the way to go.

When should you consider hybrid apps?

Hybrids will work just fine for most apps, especially B2B and when you need to build an MVP with a low cost.

Roadmap 2019

What will be going on in the hybrid apps world in 2019? Max Lynch, the Ionic framework developer, announced the release of its latest project—Capacitor. According to him: 

Capacitor will become the official native abstraction and runtime for all Ionic apps.

In order to make Capacitor the official native abstraction and runtime for all Ionic apps, the team will:

  • ship the 1.0, production-ready release of Capacitor,
  • Integrate Capacitor into our commercial DevOps product (Ionic Pro),
  • invest in more unit and automated testing to double down on stability,
  • add an index of existing Capacitor plugins and invest in plugin development guides to make it easy for developers to build native integrations. 

Some more steps waiting ahead of the Ionic team in 2019 were clearly listed on their official blog. 

Final word

As I was thinking about the title for this post, I naturally considered the very popular “something vs. something” trope, but as you can probably see by now, there are no true winners here. The paragraphs above simply outline different approaches to cross-platform development which I believe to be the future of development in general. Okay, although I doubt that hybrid apps will stand the test of time due to their UX issues, the rest of the approaches outlined above are legit and you should consider them for your next project.

Cta image