What teams are suitable for development with React Native
Originally posted on Boostlog.
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.
Summary
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.
📣 The Boostnote team launches IssueHunt for sustainable open-source ecosystem.
