React Native: A Mobile Developer’s Perspective

Does React Native truly fulfill the needs of clients? Is the development time using React Native reduced significantly?

Modeso
Modeso
Aug 21, 2017 · 10 min read

Update: We wrote a summary for you: Insights to React Native for Decision Takers

React Native has become one of the most sought out development frameworks on the top freelancing sites. So, as part of keeping up with the latest demand of new technologies, we wanted to discover for ourselves, if the praise of React Native around the web is really justified?

Ergo, we gathered four developers, two iOS, two Android developer with little knowledge of ES6 and no knowledge at all of React to learn and implement a project using React Native. In order to compare the efforts to produce a similar-looking app, we implemented a project that was previously implemented natively for both the iOS and Android platform by Modeso.

Exploring React Native

At the very start of our learning process, we tried two tutorials which covered the very basics of React Native and we felt that we were mostly copying code and not understanding much behind the code, so we switched our learning tactic and followed Stephen Grider’s Udemy course which provided us with all the basic knowledge to kickstart a project and how to handle data changes using redux.

Our biggest hinderance during the learning phase was the use of Atom and Nuclide, the official recommend IDE’s by Facebook to develop React Native. There was no auto-complete, no syntax error highlighting even with eslint activated, no debugging and for a new developer coming from IDE’s as Xcode or Android Studio, this can be very frustrating. We added some add-ons to Atom, and still, it was not enough. While searching for add-ons, we stumped upon articles supporting the switch from Atom to VSCode and we gladly switched and were extremely rewarded.

Kick-Starting our Project

Project setup was off to a good start until we tried to add crash-analysis tools. We chose to add Fabric, a reliable tool that we have used countless times. Adding it to Android Studio and Xcode, was a straightforward process, exactly as before. The problem came when we realized it only logs native crashes and not javascript crashes, we tried to add a bridge using available libraries that will log javascript crash errors to Fabric but it was not possible. So as a result, we added Sentry as well, but adding it was not simple…

Adding Sentry and the Node Module Issues

Our first real challenge was to get npm to install Sentry on Windows, it would not run the project on Android, nothing we did would make it run. Even after following the solutions posted on GitHub, only after copying the npm modules from a Mac to Windows it was possible to run the project. We did not discover this until later on after fruitless attempts to install another package on Windows and we then resorted to copying the npm modules.

Going Ahead in the First Sprint

For initial navigation, we used router-flux v3.x, which provided us with a simple navigation between screens although it had performance issues.

Most of the tasks in our first sprint were shifted to our next sprint due to the many obstacles that we faced with styling components which is very similar to CSS, something we native developers are not used to. In addition to the many incomprehensible crashes that ended up being simply fixed by restarting the package manager.

Project Progress

One of our action items from our first sprint was to work peer programming until we became accustomed to React Native, a decision that helped speed up implementation.

One tasks in the project was to add a list with indexing. We first implemented it with the now deprecated ListView and we noticed that upon fast scroll or jumping to a specific index there is a noticeable delay causing a white empty screen. We then switched to use a SectionList which greatly improved the performance. But nevertheless, we can momentarily see blank content.

Whilst the SectionList was greatly improved, it was no way similar to UITableView in iOS and RecyclerView in Android.

From there, after a steep learning curve, our project progress speed up, this was partially due to the many great articles on Medium, Hackernoon and a prominent writer of React Native, Spencer Carli. In addition, to us becoming more accustomed to React Native syntax, profiling using Perf Monitor, getting familiar with the extensive chrome debugger and understanding the crashes.

Our app consists mainly of custom UI components and different kinds of charts, natively we used each platform’s UI components and some libraries with slight modifications to implement them. In React Native we implemented the most part ourselves and used libraries as an underlying layer. The React Native implementation took longer, but not considerably, and it had the same look-and-feel and smooth animations as those implemented natively. Only slight difference was in the gradient UI effect of one of the charts.

One of the things that we greatly enjoyed using is Redux. Although initially it may seem hard to grasp, it can be used to implement anything related to data changes. The only downside was that live inspection was not possible with Redux V2.x.

Our project also incorporated Realm, which we initially expected would be complex when using it with Redux, but instead we were pleasantly surprised by otherwise.

Unit Testing on React Native Projects

For unit tests in React Native, the default testing framework is Jest, but their documentation was greatly lacking. In spite of the fact we followed the official documentation of jest and redux, the unit tests did not pass. Moreover, the snapshot tests that initially passed failed as we added more packages in components. Furthermore it was not clear where should we place the mocks, nothing was mentioned in the documentation and as we searched and looked for more resources, we came across more frameworks and it became more confusing which are essential and which are complementary like the debate between using Enzyme and Jest. Unit testing in React Native was unnecessarily a great hassle when comparing it to the Native test frameworks on iOS and Android.

Major Challenges

We did not implement the entire project as we did natively owing to the time frame and the further complications and challenges that we faced as we continued in the project. Below are some of the main challenges that we faced:

Documentation

Sometimes we would get an error, that “the function you are using is not a function” only to find, that the mentioned function was not available in our current React Native version, but what was surprisingly not stated in the documentation.

React Native Components

Third-Party Components

Usability

Integration with Existing Code Base

IDE

Debugging and Crash Analysis

Bugs

Conclusion

Is the Praise of React Native Around the Web Really Justified?

We realized, provided that we had previous knowledge of ES6 and React, project progress would have been faster. It would have helped us enhance the code, understand the component lifecycle methods better and apply more best practices that avoid unnecessary renders and long render times of components.

So, from this perspective, we can conclude, React Native is more suited for Web engineers switching to mobile development without learning native languages. Thus, React Native’s principle of learn once run anywhere.

Is the Development Time Using React Native Reduced Significantly?

During the development of our application for iOS and Android natively, there were six developers working with a total of 950 hours spent within seven weeks to complete the complete scope. Implementing the project using React Native took a total of 11 weeks development, 780 hours with 4 developers for around 70% scope completion. The look and feel of our app did look like a native app, and for the most part with some adjustments to the specifications provided in the Zeplin design, we had a similar-looking app. Although there was a noticeable difference in performance.

This myth is definitely busted! You might be able to develop an app for two platforms with smaller efforts if you intend to to make concessions to usability and visual appearance. But if your intention is to make a cutting edge app, then you’re ending up spending plenty of time fixing small issues and optimising the look and feel on each platform.

Does React Native Truly Fulfill the Needs of Clients?

Facebook pushes new updates every month, as a result, many packages/modules break due to this constant change. Compare this to the stable changes released by Apple and Google yearly. So, for a long maintenance and complex project, using React Native is not a reliable option as it is not mature and stable. In addition, due to this instability and unpredictability of the different types of errors, project time estimation will not be accurate.

React Native was a great learning experience for us. Overall we feel that React Native is at junction to a path that will lead to either a stable and promising future or will continue to be unstable and the choice for short-term projects only.


Credits: Modeso’s Mobile Engineers Olla Ashour, Esraa Yasser, Shimaa Ibrahim & Rania Elmansy.

Modeso

We Create Digital Products

Thanks to Jonas Greminger

Modeso

Written by

Modeso

Digital Solutions for Businesses & Startups. www.modeso.ch

Modeso

Modeso

We Create Digital Products

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade