React Native (RN) has been more used for application development, although RN is not the strongest library to develop native applications. I think it would be possible to create a good application using the merit well, but if I fail, it may take twice more time to rebuild it using Swift and Java, etc. It is very important to investigate the features and other company cases to decide if it’s good to adapt it according to the situation of the team. In this article, I would like to share my thoughts on what kind of situated team is suitable for RN development. This article does not include describing what RN is or how to implement it.
1.A team that wants to release as soon as possible
RN can describe / manage iOS / Android sources collectively. Also, since hot reloading is possible, the build time after any modification is short. Therefore, I think it is suitable for the team that wants to develop iOS / Android application as soon as possible. Also, because it is JS, you can use any editor or IDE as you like. Therefore, development may be more advanced.
2. A team wishing to have specifications/appearance on iOS / Android
When iOS and Android are implemented by different people, I think it is common in application development that specifications and recognition misalignment occurs, and possible / impossible things occur caused by reasons in the OS itself. There is a little chance to manage with one source in RN. Also, I think there is a suitable design depending on the OS. But if there are still places where you want to improve the design, it can be done by having the implementation done in one place. However, if there are many places where processing branches on iOS / Android, it may become difficult to read code. In such a case, it is necessary to think about the specification, such as “. Ios.js”, “. Android.js” and so on.
3.A team that WEB engineers are missing, but the native engineers are not enough.
The demand for the app is still high, and the native engineer is the seller’s market. I think native engineers are not enough for any team. However, looking for engineers other than the application, I think there are very few WEB engineers who have never written JS. If so, they can learn React and be involved in the development. Since you use Xcode and Android Studio at the time of launch, so knowledge of iOS and Android is necessary. We do not recommend adopting RN only for because it can be written with just JS alone. Native knowledge is not zero, a bit necessary. However, there is a possibility that a web engineer can help you.
4. Many designers team with no application design experience
The clear part of RN can be CSS-like. That’s gives more freedom to customize better than native. So, even if you don’t have the application design experience, I think you can deal with it at the time of development. However, there are suitable designs that seem to be apps and designs suitable for each OS, so I think it is always better to study and improve it.
5. A Team that wants to improve the application improvement cycle as soon as possible
A big advantage of using RN is that CodePush is available. Therefore, it is possible to speed up delivery. As a disadvantage of native, especially iOS, it takes time to release even if it is implemented, even if it is released, it will not be used unless the user updates / the bug is not fixed. If you use CodePush, you can quickly deliver the implementation, so I think whether it will make it easier to make minor bug fixes, design corrections, and AB tests.
6. A team that wants to match the appearance of web and app
There is React Native for Web.
At first, I think the name seems a little unnatural, but it may be better to think WEB HTML seen on a smartphone browser can be developed by wrapping it with components in RN. By using that, it may be possible to unify the design of the web and the application versions, or to make the components common to improve development speed. Although it seems to be a little difficult, I think it is good to challenge the details gradually.
7. A team that isn’t asking for the highest and fastest
Since RN goes through JS once, it can’t be faster than native implementation speed. Also, if there are engineers who can implement native properly and you have enough time, there is no merit of using RN (except for CodePush). I think it’s better to develop the application in native. However, it is suitable for the case you want to put out the initial release anyway early. So when the service scales, I think it would be nice to recruit native engineers and rewrite them.
RN is not the best solution for application development. However, I think if you use it in a suitable place, it will be very beneficial. I think it is good to study RN in the sense it increases the choice of development when placed in the environment described above.