Talking about cross-platform toolkits, there is no “best of the best” technology. Business requirements are first, technology will follow.
In this article, I’ll explain how React Native works to give you an understanding of whether it is the right choice for your software product. By describing the pros, cons, and capabilities of React Native, I’ll reveal nuances of this technology that we faced during cross-platform app development.
What is React Native?
How Does React Native Work?
In case of any updates, for example, if a user presses the button, React Native translates this case into the event that the JS can handle. And then, by relaying messages between a particular native platform and a JS codebase, the React Native bridge translates native events into ones React components can understand and respond to.
Such architecture has certain challenges. On the one hand, default components may not cover both platforms or may look very different. On the other hand, bridging architecture allows using all existing native views from platforms SDK and JS libraries.
React Native Features And Challenges
The common myth about code sharing between the web and mobile platforms. The point is that React Native is based on native mobile elements, meanwhile, React.js, used for the web, is based on the DOM (Document Object Model) elements of the browser. Thus, it is possible to reuse only logic related to a source code and business logic. The same goes for libraries — it’s possible to use only those libraries that are not related to DOM. Since the functionality and the UX and UI in the web and mobile apps are different, the refactoring for code reuse will take more time than writing a separate logic for a mobile app.
Performance and Stability
React Native is still in beta (0.62) and sometimes has compatibility issues when updating versions. But it doesn’t mean that your app is broken with every new update. It means that changes brought by updates should be made once they are proven to be stable.
Of course, there are breaking changes caused by updates, but it just means that the React Native team makes continuous improvements. In my experience, when we had bugs after version updates, they had no influence on the project due to the rapid fixes of the React Native team.
Due to the bridge architecture, some long-running events on the JS side may block UI events. Also, any actions requiring synchronization between JS code and native one may be delayed because of the time required to pass information via the bridge. For example, there might be issues with a ScrollView’s position since events about its change are rapidly emitted.
Talking about the interactive animations, that should run every 16 milliseconds, their logic goes from the JS to the Native side. Due to bridge architecture, animation events may also have performance issues. When developing React Native-based apps, we used Native Driver , which sends animations to the native side. The native code performs animations in the UI thread which allows frames to avoid going through the bridge and ensures smoother performance.
The use of the Native Driver may cover 90% of cases when it comes to interactive animations. But there are still 10% of specific cases when app functionality involves gesture events like pinch to zoom or drag and drop. In that case, it is possible to use such solutions as react-native-reanimated or react-native-gesture-handler that allows recognition and tracking of gestures on the native side and reduces bridge drawbacks.
UI and Custom Views
React Native utilizes the React.js library, which enables it to cover many cases. It doesn’t have a full set of native components, but they can be replaced with community plugins.
One of the solutions to overcome UI limitations is to use Expo, a platform with the preinstalled UI components and plugins for React Native-based apps. But when using Expo, it is important to remember that native plugins can not be used along with Expo ones.
In my opinion, the utilization of the Expo is a good idea for prototyping, MVP, and PoC solutions. It is also an optimal solution for apps with standard UI, which will not involve unique customization. If the app is supposed to have non-standard UI, it is better to use Native libraries and plugins that can be modified.
When to Use React Native
First of all, it is important to define if it makes sense to use cross-platform app development or it is better to choose the native one. If your app is mostly based on business logic and UI, cross-platform will be a good option. If the app involves more native components, then the native app development will be a better choice.
When choosing among cross-platform solutions, I would recommend React Native in the following cases:
- MVP or PoC solution that involves a simple client-server architecture.
- The team that will support an app after the release mostly consists of JS developers.
- B2B and enterprise apps.
- Apps with standard interactions and UI.
What is the Future of React Native?
Facebook’s team is currently re-thinking approaches and overcoming limitations by improving each platform’s section individually. They have already announced the new architecture, which is going to be as follows:
- Fabric module, which aims to improve the rendering layer. By creating the Shadow Tree in C++ with the help of the UI manager, Fabric improves the responsiveness of the UI.
- Priority queues from the React for the UI operations, which improves performance by having opt-in synchronous executions, thus, improving gesture handling, lists, and navigation.
- Lean Core approach, allowing to reduce the weight of a generated app and to improve maintenance on those elements not used directly by Facebook.
You might have probably heard about famous apps developed with React Native, such as UberEats, Instagram, Skype, or Discord. Their experiences are a good example of what React Native is capable of. But it doesn’t mean that any app might be implemented by following common practices. Even having an idea to develop an utterly identical app to Instagram, just a single change might make you have to reconsider your strategy.
Full article originally published at https://mobidev.biz.