React Native or Native Apps? : The importance of a “Perfect double” team
Sometimes we are thinking — what kind of developers should we hire for a commercial project? Should they have experience with React Native, Mobile or modern Web?
React Native has grown up and become one of the most powerful mobile hybrid technology. Following the latest trends, we had an opportunity to get more familiar with it in practice. But how to create a perfect team for a commercial project in React Native?
We started the work by gathering to discuss who’d be a good candidate to take part in the project since it’s quite hard to find experienced React Native developer on demand. First, we thought that just two mobile devs would be perfect, but they had little knowledge of ES6/React. So, maybe we should mix team with Mobile + Web developers?
Kind of cross-functional team?
In our company, we have three teams — iOS, Android, and Web. Team members are working on specific parts of the product, be it client, API or design. To help us keep in touch, we have daily standups, team meetings, and Slack. Transparency is the key.
This time we had to work together on the same „side” — a mobile application. Since each of us has a different experience in specific parts of React Native and mobile development, we could combine our knowledge and help each other. From the Web developer point of view, it wasn’t so hard to get into the React Native world.
Beginning the early research
As a company with a lot of experience launching successful (native) mobile projects, it was our recommendation to also consider native iOS / Android app. But our task was to create an app from scratch and deploy the MVP stage for both platforms, and we had to do it ASAP — so why not try React Native then?
We started from checking what are the core features of the project, what is supported in RN and where we see potential risks. Then our next step was to establish our technical stack. It was a great research time for both of us as we wanted to make sure everything we use is recommended, not overly complicated and stable. We used my Web development experience and prepared a well-tested technology stack that we were using in our company for years — turns out a lot of it is also supported by React Native!
Let the journey begin…
The project started with a good amount of research. We wanted to try and see if it was possible to add core libraries of our stack as MobX + MST, Native maps, GraphQL… sounds like regular web stack, doesn’t it? First launch of the app and… voila! It works on both Android and iOS! The main component which was a map had to be well tested before we could decide which map provider we want to use in our project. It was also a good task for an experienced native mobile dev to compare them. What we needed in terms of features were customised pins, directions, zones, clusters and — last but not least — performance.
Broader perspective when choosing external providers
We started our tests with Google and Apple maps. They seemed to run very well on each platform and had what we need, customizable pins, zones… Then we tried the Mapbox provider as it was recommended by one of colleagues and it also looked great. Now the main task was to check the performance with some benchmarking. And this is where the fun begun…
We created a simple benchmark with X markers and Y zones with an algorithm to merge pins into zones and grabbed 4 different phones ( 2 Android and 2 iOS ). Here are the results of time, RAM usage and FPS:
2000 markers, 100 zones
An interesting difference between both platforms with Google Maps is that it takes almost 8x longer on Android to finish running the algorithm, but it takes 30MB less RAM and has almost twice the FPS than on iOS. Mapbox performs better in both memory management and frames per second, which from user’s point of view is the most important part. It’s consistently at least twice better, but we suspect it might be because of differences in our zone calculating algorithm and not the map library itself. Also, from what we gathered, Mapbox renders entire data set at once while Apple and Google maps load markers one by one which is much slower, especially with larger amounts of them.
This nicely proves that for React Native developers it’s worth comparing and benchmarking solutions on both platforms as there can be huge differences in performance.
Project Progress
Super excited with this research, we started adding more libraries like Firebase, React Native Navigation, Mapbox to build the first stage of our app. We needed to customize the map’s wrapper a little bit due to requirements of the project, so it was necessary to tweak the native code. This was quite an easy task for our mobile developer and preparing the patch took only a couple hours. After first two sprints, we had fully working React Native app with the most important features already ready to be tested. Perfect!
Another thing we greatly enjoyed was using MobX with Mobx State Tree. It was super easy to create basic stores with everything we needed and persist them using snapshots. And it was super fast to write!
What we loved
React Native Components
React Native components allows to organise project and keep the code clean. To keep our components well organised, we decided to stick to the screen based structure which worked very well in mobile environment.
Customisation
Imagine that when you’re done 80% of your features — what’s gonna happen when some parts of that feature are not supported by React Native or any 3rd party lib?
Well, considering RN is a bridge between JS and native code, you can easily create another bridge between your Javascript code and any feature possible in native iOS/Android app. We had a chance to try it while we were customising NFC tag support a bit and it was a pretty nice experience — awesome!
Community
In React world we have a lot of useful open source off the shelf libraries and components. The great thing about this community is that for most of the issues we have faced there was either a tutorial or solution on GitHub or Stack Overflow. I see the trend for React Native is growing and there are more and more shipped to production projects which add more contributors.
Integrated Development Environment
IDE for React Native was something new and worth to check. Earlier I was using Ruby Mine by IntelliJ, with some extra plugins and I was able to create a dev-friendy environment for React. My mobile developing friend was using XCode. As a part of the research, we wanted to have one consistent IDE, which supports Flow type checker. Lots of people were recommending VSCode, so why not? After just one day of using it, we both loved it.
What we disliked
Debugging and Crash Analysis
Web debugging in React is a pleasure, in Native — not so good. A web server has multiple threads and lots of processing resources, same with a laptop with a browser. In React Native we are depending on specific phone’s processing power. Any bug reporting tool we add takes extra resources which makes a phone more and more laggy. We’ve noticed that debugging was also very slow on a device, specifically on Android devices.
UI differences between iOS/Android
The problem with iOS and Android is not only in the design or capabilities. I’ve noticed that sometimes when adding gradient layer on screen/map, on iOS it worked perfectly normal but on Android, it was covering the whole screen. DevTools showed that on iOS and Android layers were nested differently which made some things quite tricky (but doable) to fix.
Not every native feature is available as a wrapper
Imagine there’s a new requirement — you have to change the color of user heading. In API documentation it all looks fine in both SDKs, so you think it’s not a big deal. Well, not exactly… we were using Mapbox for both iOS and Android, and the wrapper library did not have the option to change it implemented. We had to take a look at the examples in the documentation for both iOS and Android and add support natively, and then wrap it to React Native. The same situation happens when you’re having the misfortune of triggering a bug in the framework itself, making you either wait for the new release or having to contribute yourself which for a non-native developer is not so easy.
All of these problems take time so even if we save time on building the app for two platforms at the same time, we may eat through our savings when solving problems that seem simple.
Conclusion
What team do we need for React Native project?
It’s a hard question. For new projects when a company need to choose from its ranks, it’s hard to gather “perfect team,” so usually it’s a mix of React and mobile developers (it’s a bit easier for mixed-competence team to get into React Native than for mobile devs only).
It was not only faster — we already had a tech stack that was battle-proven on the Web but also iOS/Android experience helped us choosing libraries and figure out proper native configuration and most importantly, fill the gap when there is no React Native solution for a part of a feature.
Should we worry about React Native on production?
It’s kinda outdated question, to be honest. We had some doubts at the beginning if React Native can handle all the use cases that we need. Surprisingly it’s easy to add new features/support to RN manually if you know iOS/Android. There are also constant updates (usually every month). It may lead to some breaking changes, but at the end of the project we updated all packages (after couple months), and the app ran without problems so your results may vary. I would say React Native is becoming more mature and stable, but for now native iOS/Android sounds more reliable if you have the time and good team to take care of the development.
React Native was a great experience for us. We feel that it’s becoming better and better and it’s already ready to use in production. Though we still recommend using native apps for long term projects.
Read more:
- Testing React Components
- Refactoring RecyclerView adapter to data binding
- GDPR in Machine Learning Projects
- From MVP to MVI — Model-View-Intent Journey Part I
- From MVP to MVI — Model-View-Intent Journey Part II
- Swift Playground — Bluetooth Low Energy
