React Native vs NativeScript: shipping cross-platform in 2018.
Two ways to write one app for iOS and Android. We've shipped real production work in both. Here's the head-to-head comparison, the decision tree we apply on every brief, and the real-project case study where we picked NativeScript and it paid off.
Every time a client asks for an iOS and Android app on the same budget, we have the same internal conversation. React Native or NativeScript? Both render to real native UI. Both let us share most of the code. Neither is right for every brief. Some honest field notes after a year of running both in production.
The two products, in plain terms
React Native is Facebook's open-source framework for building native mobile apps using React. You write components in JSX, the framework translates them into native iOS and Android views at runtime via a bridge layer.
NativeScript, by Progress, lets you write native apps in JavaScript or TypeScript using Angular, Vue, or vanilla JS. There's no bridge in the React Native sense — NativeScript wraps the native APIs directly, exposing iOS and Android classes as JavaScript objects you call.
Comparison, side by side
| Concern | React Native | NativeScript |
|---|---|---|
| Frontend framework | React only | Angular, Vue, or vanilla JS |
| UI rendering | Native views via bridge | Native views via direct binding |
| Native API access | Bridge — write Objective-C / Java module | Direct — call iOS / Android classes from JS |
| TypeScript | Supported via plugins | First-class, default |
| Hot reload | Yes | Yes |
| Native dependencies | CocoaPods / Gradle | CocoaPods / Gradle |
| App store distribution | Standard iOS / Android | Standard iOS / Android |
| Community size | Very large (~500k stars) | Smaller (~18k stars) |
| Backing | Facebook (Meta) | Progress Software |
| Plugin ecosystem | Very large — npm + react-native-community | Smaller but generally well-maintained |
Where React Native shines
- 01If your team already lives in React, you're on the runway. The mental model transfers cleanly from web React to mobile React.
- 02The community is massive — every odd native module you need probably already has a wrapper on npm.
- 03Facebook puts real resources behind it. The roadmap is loud and consistent.
- 04Hiring is easier. 'Mid-level React developer' is a category every recruiter understands.
- 05Hot reload is excellent — instant feedback while developing, no full app rebuild needed.
- 06Microsoft now uses it for Skype, Walmart for their main shopping app. The 'is this production-grade?' question is essentially answered.
Where NativeScript wins for us
- 01Vue 2 support is excellent. Our team writes Vue every day for the web — sharing the model with mobile is a cognitive win.
- 02Direct access to native APIs without writing a bridge. iOS classes and Android packages are addressable from JavaScript with the actual class names — UIImagePickerController() from Swift looks identical in NativeScript JS.
- 03TypeScript support out of the box, not retrofitted.
- 04The bridge isn't a serialisation bottleneck the way React Native's was for parts of 2017 (the New Architecture / JSI rewrite addresses this, but it's not stable yet).
- 05Better for native-heavy workflows — Bluetooth, advanced camera, sensor fusion. No 'wait for a wrapper' step.
- 06Easier to integrate with existing native iOS / Android code if you're rescuing a legacy app.
How we actually decide
- 01Team — if the existing engineers know React, RN. If they know Vue or come from native iOS / Android, NativeScript.
- 02Native API surface — if you're going deep into camera, Bluetooth, sensors, NativeScript's direct access removes a class of bridge bugs.
- 03Ecosystem — if you need ten obscure third-party plugins, RN has more of them maintained.
- 04Long-term ownership — Facebook's commitment to RN is more visible than Progress's commitment to NativeScript. That matters for a five-year horizon.
- 05Hiring outlook — RN developers are easier to find. If the client will own the app post-launch, this matters.
The right answer is almost never 'whichever is technically superior'. It's 'whichever fits the team that will own this app in eighteen months'. Pick the framework your client's next hire will already know.
Case study — The Roadkill App
For The Roadkill App — a global iOS / Android app for citizen-science roadkill recording — we picked NativeScript. The brief had heavy GPS, voice activation, image capture, and offline-friendly design requirements. Why NativeScript won the bake-off:
- 01Voice activation needed direct access to AVAudioSession (iOS) and SpeechRecognizer (Android) — NativeScript called both natively without a wrapper. Saved us roughly a week of bridge work.
- 02The camera pipeline needed custom exposure control. We'd have had to write a React Native module from scratch; in NativeScript we wrote it in a day.
- 03Vue 2 is the team's daily language — onboarding the third engineer took half a day rather than the two weeks it would have for React Native.
- 04Offline-first data flow used Couchbase Lite via direct NativeScript bindings — RN's wrapper was 18 months out of date.
Six months in production, the app has shipped to 14 countries and has zero crash reports tied to the cross-platform layer. The direct native API access paid off in week three when we needed something the RN ecosystem didn't have a clean wrapper for. No regrets.
What we think changes
In the next 12-18 months we expect React Native's New Architecture (Fabric + TurboModules + JSI) to close most of the performance and bridging gaps that gave NativeScript its edge. When that ships, the React Native default position will strengthen. NativeScript's niche will narrow to 'we have a Vue team and we want to share code'.
Both frameworks are alive, well, and in active development. Neither is going away. The brief decides. Ask the right questions early and you'll pick the right one.