React Native vs Flutter vs Ionic vs NativeScript vs PWA

How does React Native compare to Flutter, NativeScript or Ionic? What are the differences? Which one should you learn? How's performance for each of these options? I chose 8 metrics to compare these technologies and help you with that decision.

This article will compare Flutter, React Native, NativeScript and Ionic.

All four technologies allow you to build real native mobile apps for both iOS and Android - without the need to learn Swift, ObjectiveC, Java or Kotlin!

Instead, you'll use JavaScript (for React Native, NativeScript and Ionic) and Dart (for Flutter). Hence you're able to create native apps for both platforms with one language instead of two - this obviously reduces the learning effort you have to take to build your mobile app by a lot!

Great! So how do these technologies differ, which one is the best choice for your next mobile project? Let's take a look...

Flutter is both a SDK (software development kit) and a framework for Dart - a programming language developed by Google. Flutter itself is also developed by a Google team.

The idea behind Flutter is that you write Dart code which can be compiled to native code that runs on the target device. You use Dart + the Flutter framework to build user interfaces composed of so-called widgets. Flutter ships with a bunch of pre-configured widgets (buttons, tabs etc) and you typically use these to then also build your own, more complex widgets.

You can of course learn all about Flutter in our very detailed course.

Besides writing Dart/ Flutter code, you'll also use the SDK portion of the technology. That basically is a set of functionalities that help you during development (IDE extensions, development server, live-updating of your app on an emulator or real device) and with deployment (compile your app code to native code).

React Native is a technology/ framework developed by Facebook.

It uses JavaScript and the React library to allow you to build beautiful user interfaces composed of React components.

Important: Unlike in "normal" React apps built for the browser, you'll NOT use HTML tags. Instead, you'll use a set of pre-built components which will be compiled to native code by the React Native toolchain.

You're still able to use packages like Redux and knowing JavaScript and React of course allows you to quickly get started with React Native, too.

Just as with Flutter, you can dive into our detailed course on React Native.

NativeScript also uses JavaScript to build native mobile apps. It comes in different flavors - pure JavaScript/ TypeScript, with Angular and with Vue.js.

It gives you the option of working with different frameworks as you can see - the different options are developed independently from each other though. So you might have an easier time or more built-in components with option A than you have with B. All options are under active development though, hence it's best to simply dive into the docs.

Like Flutter and React Native, NativeScript also ships you a bunch of pre-built components which you use to compose user interfaces. It does not work with HTML but with its own components (like React Native).

Ionic follows a different approach than the first three options!

With Ionic, you still create a real native app but you do this by creating a web app (with HTML, JS and CSS) which will be wrapped by a real native app that hosts a webview (basically a hidden browser).

Since you build a web page in the end, Ionic is pretty easy to get started with for web developers.

Starting with Ionic 4, Ionic is basically a huge suite of components you can use (buttons, cards etc) with any frontend framework (or none at all).

Ionic also provides a lot of tooling that makes the development of mobile apps easier (e.g. a development server for running your app on an emulator/ real device with live-updating) and it also bundles the app into shippable packages. Additionally, the Ionic team is involved in the Capacitor project which offers a lot of JavaScript packages you can add to any (!) web project to tap into native device features like the camera.

Want to learn more about Ionic and build some real apps with it? We also got a course on that topic :-).

After these brief introductions - how should these options be compared?

Let's also add the native platform languages (Java/ Kotlin for Android, Swift/ ObjectiveC for iOS) to the mix and have a look at eight totally subjective metrics.

With this metric, I want to explore how much of the code you write can be re-used for both platforms.

Don't get me wrong - the whole idea behind all these technologies is to re-use code and only use one language but you might still need to write different code (despite using the same language) for the different platforms.

This could be required to position elements differently or because you need to use different UI components as not all UI elements exist on both platforms.

We see mixed results.

• Ionic: Awesome re-usability! The "wrapped web app" concept ensures that you can easily re-use your code - you're just building a wrapped web app in the end. The great component library of adaptive components (i.e. automatically styled for the platform the app runs on) also helps.

• Flutter: Also really great to re-use. The widgets it ships with often don't adapt to the underlying platform, instead you use Material Design on both platforms by default. The Flutter team is providing more and more iOS-styled components though. You can find out on which platform you're running and manually swap widgets but that's of course a bit more work than required by Ionic. If you need platform-specific re-styling, you can move the position of Flutter on the slider further to the right.

• NativeScript: Pretty similar to Flutter, but it does not apply a style system by default though. Many components automatically compile to their native equivalents and therefore need no re-styling (unless you want to). Components that do not exist on both platforms have to be managed by you (i.e. you have to decide which component to render on which platform). Overall, code can be re-used quite well though.

• React Native: Also compiles to native defaults but only provides a basic set of components to start with. You have to style most of them on your own, hence more work is required to achieve appropriate styles on both platforms. Generally, code can be re-used though (since you still only use one language and libraries like Redux need no adjustment).

• Native Languages: Obviously you can't use Java with Android for iOS development (or the other way around). Therefore, code re-usability across platforms does not exist here.

This metric sounds similar to the previous one but it actually means something totally different. Even if you have to adjust some code to the underlying platform, the question is: How complex is that adjustment? Do you have to learn different language features for the different platforms?

On this metric, we got basically two extremes in my opinion. All options except for using the native languages require only one language to be learned. That is true for both solutions like Ionic - which follows a "use one codebase for both platforms" approach - and alternatives like React Native, where some differentiation may be needed.

How easy is it to build beautiful UIs? Do you have to create and style a lot of components (UI elements) on your own or do you have a rich suite of pre-built ones? Are the components adapting to the underlying platform automatically? That's what this metric is about.

On this metric, the options differ a lot!

• Ionic: Ionic in its core is a big set of pre-built (and pre-styled) components. The compiler/ toolchain which yields a native app is also part of the Ionic package (handled via its CLI) but it utilizes other packages like Cordova or Capacitor. The components provided by Ionic automatically adapt to the platform the app runs on and therefore, Ionic makes the creation of beautiful, native-looking apps a breeze!

• Flutter: Flutter also ships with a comprehensive suite of built-in widgets. These mostly use the Material Design, some Cupertino-style (iOS style) widgets exist, too. More and more iOS-styled components are getting added. With all these widgets, you can quickly create nice-looking UIs without doing too much manual styling. Only if you need different looks for different platforms, some effort can be required since the widgets don't adapt automatically.

• NativeScript: NativeScript ships with a decent set of UI elements which comprises the core set of elements you typically use. Not every niche component is included but the components it does ship with adapt to the underlying platform. Still, some manual styling is most likely required, additional widgets might need to be created by you. It's certainly less comprehensive than Ionic or Flutter.

• React Native: A decent set of built-in components is provided but a lot of them need to be styled by you. And they're non-adapative, instead - just as with Flutter - you get alternatives for both operating systems. That requires adjustments in your code, where you have to choose, use and style widgets conditionally.

• Native Languages: As you'd expect, both languages/ frameworks ship with a rich suite of native UI elements which you can use to build your user interfaces. Obviously, they're non-adaptive since you build your UI for only one platform at a time. But the components provide the default platform styles and can of course also be customized.

What does the ecosystem look like? Is it easy to find help (on Stackoverflow etc) and are there enough third-party libraries available to add that one feature your app needs?

• Ionic: Ionic uses JavaScript for its logic - and whilst you can use it with any (or no) JavaScript framework, it provides especially great support for Angular. Therefore, you benefit from these ecosystems. And the JavaScript as well as the Angular ecosystem is huge! Thousands of threads on Stackoverflow and packages on npm help you solve your problems.

• Flutter: Flutter is seeing tremendous growth! You find quite a lot of discussions on Stackoverflow and third-party libraries and packages (on its own platform). Despite being relatively new, it's already quite mature and has a decent ecosystem.

• NativeScript: NativeScript lags behind a bit. It's actually a great SDK/ framework but somehow, it didn't fully take off thus far. But it looks like it's gaining some traction at least and you do find more Stackoverflow threads and third-party packages. Additionally, new initiatives like Nativescript-Vue show that the community is very active and also allows you to use a framework other than React and Angular to build your native mobile app.

• React Native: It's THE most popular solution for building native mobile apps with JavaScript. At least when we look at the alternatives that really compile your app to native code. It uses JavaScript and React, hence you got those ecosystems available. Additionally, React Native on its own has quite a vibrant ecosystem and community, hence you find many threads on Stackoverflow and a lot of third-party packages that add missing functionalities. A downside is that you often need to rely on the ecosystem, since only core features are included in React Native itself.

• Native Languages: These languages are extremely popular and therefore Stackoverflow is exploding with threads on them. You find plenty of libraries you may use and you therefore probably won't find an issue that can't be solved.

Having a vibrant ecosystem is a good thing - but how popular is an option? This is not necessarily the same, as you could have a rich ecosystem due to the alternative being mandatory in an industry without it being very popular amongst developers.

• Ionic: Ionic is pretty popular. It empowers (web) developers to build native mobile apps in the fastest possible way. If we take Github stars as an indicator, we can see that it has around 39k stars at the moment I'm writing this (14th August 2019).

• Flutter: Flutter had a strong year on Github (72.6k stars, up from 30k stars a year ago) and is still extremely trending. It's heavily advertised by Google and they clearly want to make it a big thing. And it's fairly well-received. Working with it is really fun!

• NativeScript: As mentioned before, NativeScript is not the most popular option. It has 17k stars on Github (14k a year ago) and you can "feel" that it's less popular. But this might be changing. Lately, a lot more positive comments and discussions spun up and initiatives like NativeScript-Vue definitely bring more live into the ecosystem.

• React Native: React Native is the king. 80k stars on Github (65k a year ago) speak a clear language. It actually has its flaws and if you dive into discussions, you can see that not all developers are loving it. Not everything works flawlessly but overall, it uses an extremely popular library (React) and the most important web development language (JavaScript) and gives you real native apps. These are indeed very strong arguments and the reasons for its popularity.

• Native Languages: You don't find Android and iOS on Github, so I can't provide any stars. But these two options ARE very popular. Have a look at the books, courses, articles, threads and media coverage that exists on these technologies. If someone wants to build an app, he's most likely looking into the native languages first.

This metric probably speaks for itself - how do the different technologies compare from a run-time performance perspective?

• Ionic: Ionic offers the worst performance as its a wrapped web app in the end. But this is often misunderstood! "Worse" sounds extremely bad but "worse" doesn't actually mean "bad" or even "horrible". Instead, you got worse performance than with the other approaches but on the devices we got these days, your app will probably run more than smooth! If you only (imaginary!) got 100fps instead of 105fps - would you notice a difference? You wouldn't, so keep Ionic in your mind for your next app!

• Flutter, NativeScript and React Native: These three all offer you real native apps (compiled from your code) and therefore, they provide a better performance than Ionic does. Doing exact measurements on who of the three is best is pretty hard or even impossible as it depends too much on the app you're building, the device you're using, the operating system and the version of Flutter/ NativeScript/ React Native used. They all provide really good performance, that is what you need to know!

• Native Languages: Well, you probably can't beat the native languages. Well-written native code should always be more performant than compiled native code.

Your mobile apps most likely need access to some native device feature like the camera or GPS. How easy is it to get that access? And how easy is it for relatively new features (e.g. AR APIs provided by Android/ iOS)?

• Ionic: Ionic uses Cordova or its own solution, Capacitor, to give you access to native device features. It provides a very decent set of packages to access common native device functionalities like the camera. You can also write your own wrappers around native functionalities and then include them in your code of course.

• Flutter: Over the last year, the Flutter team put a lot of effort into providing official packages for some of the most common native device features you need access to. There also is a very vibrant ecosystem and hence you find a package for pretty much any native feature you might want to access. You can also write and connect real native code if you need to.

• NativeScript: NativeScript offers a very decent set of plugins (developed both by the NativeScript team as well as other developers) that give you access to the important (and even some less-common) native device features. Additionally, it's also easy to connect your own native code to your NativeScript app.

• React Native: Being the most popular solution, you find a rich set of third-party packages as well as some built-in APIs for accessing native platform functionalities. Relying on third-party packages (which you mostly have to do) of course has the disadvantage that the core maintainers of that package might quit, hence the support is not on the same level as it is with Ionic or NativeScript.

• Native Languages: Needless to say, that you got ALL APIs for a given platform available here. You are directly accessing the native APIs after all.

It's great if you're convinced about a technology - but how does the rest of the world think about it? This might not matter to you but if it does - here's a quick comparison.

• Ionic: Ionic still has no ground-breaking killer app but it has a nice showcase of apps that are using it. Some bigger companies are using it and the speed of development you can achieve with Ionic is probably especially appealing to highly agile and/ or small teams. Not meaning that no bigger companies are using it (as you can see in the showcase).

• Flutter: Despite being relatively new, Flutter already has some exciting apps being built with it - Google's AdWords app for example. You can find a full list in their showcase, chances are that we'll see more great apps on that page soon.

• NativeScript: You find some big names in its showcase, mostly companies from the B2B tech space. And a lot of apps seem to be internal apps (or apps for the clients of these companies). If we consider B2C, there seems to be no killer app available - that is probably related to the lower popularity of NativeScript.

• React Native: React Native is used by a couple of bigger companies, Facebook itself (which develops React Native) for example. But we also have to note that one big company which used it - AirBnB - lately moved away from it. Probably also because of that article, the RN team is working on getting rid of some of the mentioned limitations and problems.

• Native Languages: The vast majority of apps available is written in these native languages. You find thousands of big apps and games that use these languages.

With all these metrics discussed - which one should you choose?

There is no bad choice here, these are all great alternatives!

First of all, you have to decide whether you want to stick to the native languages (Swift, ObjectiveC, Java) and accept the disadvantage of learning two things and writing two apps. This is a lot of work and mastering two languages and platforms is way harder than mastering one. But you saw a couple of "pro" arguments, too.

If you don't want to use the native languages, you have to decide whether you want a wrapped-app solution as Ionic offers it. Whilst having the performance disadvantage (which might not matter that much as discussed above), you will get a super-fast development experience. You can use your web development know-how and build two apps with one tech stack in little time.

But if performance is super-important to you - or you need to access a lot of (advanced) native device features - you might want to take a look at React Native, Flutter or NativeScript. Here, the details outlined above matter as these approaches are pretty similar otherwise.

Once you made your decision, you can dive into your favorite option with one of our courses.

Time for the surprise alternative!

You could also build a Progressive Web App (PWA)!

A PWA is a web app, not a mobile app. This is really important to understand - you won't distribute it via the app stores!

But it looks and behaves like a native app, you also have access to a decent amount of native device features in modern browsers.

PWAs are built in a way that allows them to run in older browsers, too, though. They'll fall back to alternative versions if feature A is not available.

This makes them a good alternative for many but not all use-cases. If you absolutely need device-camera access, a PWA might not be the right choice since you can't control whether your users use a browser that provides that access.

But in other cases, PWAs are a great alternative - and skipping the app stores is actually a plus since users don't install many (unknown) apps from these stores.

If you want to build a PWA, you can learn it with our complete guide - and with Ionic 4, you'll even be able to build a PWA and native apps with one codebase!

So definitely explore this alternative, too.