--- title: "React Native vs NativeScript: shipping cross-platform in 2018." date: 2018-04-26 url: https://remiam.co.uk/notes/react-native-vs-nativescript-2018 tags: [Mobile, NativeScript, React Native, Comparisons] read_time_minutes: 9 description: "React Native vs NativeScript in 2018 — head-to-head comparison from a studio shipping real production work in both, including a case study from The Roadkill App build." --- # React Native vs NativeScript: shipping cross-platform in 2018. *Published 2018-04-26 · 9 min read · by Liam (Remiam)* 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 | *React Native vs NativeScript — feature parity as of April 2018.* ## Where React Native shines - If your team already lives in React, you're on the runway. The mental model transfers cleanly from web React to mobile React. - The community is massive — every odd native module you need probably already has a wrapper on npm. - Facebook puts real resources behind it. The roadmap is loud and consistent. - Hiring is easier. 'Mid-level React developer' is a category every recruiter understands. - Hot reload is excellent — instant feedback while developing, no full app rebuild needed. - Microsoft 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 - Vue 2 support is excellent. Our team writes Vue every day for the web — sharing the model with mobile is a cognitive win. - Direct 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. - TypeScript support out of the box, not retrofitted. - The 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). - Better for native-heavy workflows — Bluetooth, advanced camera, sensor fusion. No 'wait for a wrapper' step. - Easier to integrate with existing native iOS / Android code if you're rescuing a legacy app. ## How we actually decide - Team — if the existing engineers know React, RN. If they know Vue or come from native iOS / Android, NativeScript. - Native API surface — if you're going deep into camera, Bluetooth, sensors, NativeScript's direct access removes a class of bridge bugs. - Ecosystem — if you need ten obscure third-party plugins, RN has more of them maintained. - Long-term ownership — Facebook's commitment to RN is more visible than Progress's commitment to NativeScript. That matters for a five-year horizon. - Hiring 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. > — Internal mobile decision matrix ## 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: - Voice 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. - The 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. - Vue 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. - Offline-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. ## References 1. [React Native — official site](https://reactnative.dev/) 2. [NativeScript — official site](https://nativescript.org/) 3. [React Native New Architecture overview](https://reactnative.dev/docs/the-new-architecture/landing-page)