The React Native team recently surveyed React Native developers with a single question: “What do you dislike about React Native?”. Developers overwhelmingly mentioned developer experience, including debugging, as their first grievance. Community handling, and documentation were also prominently featured as pain points. A significant number of developers additionally wished React Native’s application programming interface (API) would extend to cover recurring use cases, such as working with SVG. Some developers also pointed at remaining efforts towards realizing React Native promise of a seamless, cross-platform, development tool for native-like apps.

A majority of answering developers regretted that upgrading required a lot of effort and took too much time. Jan Hesters explains:

Upgrading from one version to another is hard and requires a lot of work. Especially when you have fallen a couple of versions behind and have to manually upgrade from yours to the latest version by version.

Developers point at a subpar debugging experience. For instance, Sébastien Lorber says:

I dislike that it’s often not really easy to find the root cause of an exception. The stack trace in Chrome debugger console often leads to ExceptionManager and not the original place, which lead to time consuming debugging. Using componentDidCatch does not really help.

Developers also mentioned tooling as a possible source of improvement for React Native: Hot reloading does not always work, stylesheets may benefit from optimization, some tools emit too many warnings or cryptic errors. Outdated dependencies may constitute a hurdle, and working with Cocoa requires significant work. Tycho Tatitscheff details the issue:

Cocoapod is not well supported. It breaks quite often when upgrading. Breaking are so regular that @orta build a plugin to autofix react native issues: https://github.com/orta/cocoapods-fix-react-native.

Cocoa is Apple’s native object-oriented application programming interface. CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects. For iOS, tvOS, and watchOS, a similar API exists, named Cocoa Touch.

Some Windows developers express dismay for the poor perceived developer experience on their platform. Attila Szeremi says:

The experience developing for React Native is horrendous in these platforms. The file watchers don’t seem to catch on to file changes very often. Worst of all, hot reloading often only works for the first five or so times, and then from then on it just gets stuck completely, and I would have to restart the bundler over and over again.

Some developers go as far as suggesting replacing JavaScript as a React Native development language with Swift / Kotlin. Ilja Daderko enumerates the advantages:

I’m sure this one comes up a lot and I understand the scale of work that is needed to rewrite rn in these languages, however I found Swift and Kotlin much friendlier for people familiar with JavaScript. This can lead to more OSS contributions and custom native modules from JS devs, since learning curve of Swift / Kotlin is not as steep as ObjC / Java.

Developers perceive a lack of involvement of the React Native team with the community, which translate into slow response times for issues on Github and unresponsiveness to Pull Requests (PRs). This may discourage developers contributing to React Native’s open source project. As a matter of fact, some developers relay that the contributing process is unduely complex. The perceived lackluster community support creates also, according to some developers, general uncertainty and lack of confidence in the future of React Native.

Documentation-wise, developers would like more trouble-shooting information addressing common failures or known issues. A developer gives a concrete example:

It is almost impossible to know how to properly configure KeyboardAvoidingView, partially because the documentation is so ambiguous on when to use what behavior, partially because its inconsistent across uses based on other circumstances (In/near a scrollview, etc).

I feel a solution could possibly just be better documentation around it, or adapt a strategy like react-native-keyboard-aware-scroll-view

https://github.com/APSL/react-native-keyboard-aware-scroll-view

Van der Auwermeulen Grégoire gives another example:

Often have the issue while bridging that the ReactJS lifecycle events on the JS thread, are not consistent with the Native lifecycle events. We need more documentation on advanced and specific bridging issues.

While developers recognize that instructions guides exist for beginners, they however mention the need for specific documentation targeted at library developers, for instance addressing the advanced or hidden features inside React Native, or the measuring and optimization of performance.

When it comes to the API surface of React Native, some developers would like to see some functionality provided by third-party libraries integrated in the core. This is the case for SVG images, navigation, view recycling, Push Notifications, camera, video, audio, fingerprint, motion-based interface.

Other developers suggest that React Native fails at providing a native-like experience for users. Startup time remains a crucial differentiating factor between real native apps and hybrid apps, such as those developed with React Native. For others, React Native also fails its cross-platform promise, providing a better experience on iOS than Android. Adam Burdette elaborates:

Android is still a second class citizen. Many issues apply only to Android that are fine on iOS and lead to many devs missing Android issues during development.

Examples:

{0 && <View />} will crash on Android. Any unexpected falsey value will cause Android to crash with no error screen. You MUST ensure it is a boolean value that is returned. iOS handles this fine. On Android, you cannot name a property flex or the app will crash Toggling secureTextEntry has been broken for years I’m sure there are many other examples, but Android should be a primary focus for development going forward to better support the claim of being cross platform.

The smallest category of pain points mentioned by React Native developers relates to the UI: styling and styling inconsistencies, zIndex inconsistencies, automatic scrolling, inverted lists, or image dimensions.

This article has, as its main source, a Github issue in which the React Native team invited developers to expose their list of grievances related to their experience with React Native. We analyzed 81 answers, gathering 5,486 likes, and aggregated in 6 categories. The categories are, in decreasing order of likes: Developing and Debugging, Community Investment, Documentation, API, Efficacy, UI.

React Native is a framework for writing native mobile apps using JavaScript and React. Like in React, developers describe the user interface as a component tree. Unlike React (which uses React DOM as a renderer), component trees are rendered using the mobile device’s native APIs. On iOS, that means that React Native components render to real UI Views, while on Android, they’ll render to native View. The JavaScript layer and Native layer communicate using a piece of software called a bridge.

Developers targeting a mobile platform have a set of technologies and stack available. Three categories of applications are generally distinguished: mobile web apps, hybrid apps, and native apps. Native applications are developed for a specific platform with the corresponding technology and installed on a computing device. Web applications are developed with web technologies and may be used in multiple platforms, through a browser. Hybrid applications combine elements of both native and Web applications. They are usually cross-platform, while being developed with a custom set of technologies which is independent of the targeted devices.

A non-exhaustive list of frameworks for hybrid application development include React Native, Flutter, Xamarin, or Ionic.