The three biggest issues I have with it are these:
1) Language. Elm has set the standard for web languages and after using it for a while, JS or many of the popular replacements such as TypeScript are plain insufficient when it comes to providing as many compile-time safety guarantees. Doesn't help that I'm getting into Idris and even Elm's shoes are starting to feel a little too tight.
There's a project to write Elm and target React Native, but it's still too immature and it makes the next two issues worse.
I've yet to look at RN development through a BuckleScript stack, so that may be an acceptable alternative (even if not as safe as Elm, but on par/better than Kotlin)... but won't help at all with the next point.
2) Requires very complex tooling. This complexity will rear its ugly head when doing anything slightly out of the ordinary. All solutions (including Expo) I've seen seem to suffer from that issue, just with different defaults and different amounts of work necessary for different tasks.
I am not oblivious to why this is, since RN is not only based around the JS ecosystem and all the insanity that comes with it, it also has to deal with being a fat abstraction over native rather than take the easy way out, rolling its own cross-plat rendering and give up native widgets.
3) While it has come a long, long way, performance on old Android devices is still not always as smooth as native. I'm not sure how much this can realistically be improved since the bottleneck is interop, and avoiding it or shifting work around between native and JS is just not something I want to worry about.
However, this third point has improved so much I'm ready to handwave it away if the former two weren't a thing.
Lastly, not an issue with React Native itself, but JetBrains absolutely has the intention to bite into iOS' territory with Kotlin Native... and assuming they can pull off a half-decent adaptation of Apple's APIs I'm betting they will be the ones to finally take the x-plat cake, which makes it hard for me to believe investing time and code into RN solutions is a better proposition than native.
Hope that was useful in some way. If I should clarify anything or I have any misconception about RN please let me know.
1) Language. Elm has set the standard for web languages and after using it for a while, JS or many of the popular replacements such as TypeScript are plain insufficient when it comes to providing as many compile-time safety guarantees. Doesn't help that I'm getting into Idris and even Elm's shoes are starting to feel a little too tight.
There's a project to write Elm and target React Native, but it's still too immature and it makes the next two issues worse.
I've yet to look at RN development through a BuckleScript stack, so that may be an acceptable alternative (even if not as safe as Elm, but on par/better than Kotlin)... but won't help at all with the next point.
2) Requires very complex tooling. This complexity will rear its ugly head when doing anything slightly out of the ordinary. All solutions (including Expo) I've seen seem to suffer from that issue, just with different defaults and different amounts of work necessary for different tasks.
I am not oblivious to why this is, since RN is not only based around the JS ecosystem and all the insanity that comes with it, it also has to deal with being a fat abstraction over native rather than take the easy way out, rolling its own cross-plat rendering and give up native widgets.
3) While it has come a long, long way, performance on old Android devices is still not always as smooth as native. I'm not sure how much this can realistically be improved since the bottleneck is interop, and avoiding it or shifting work around between native and JS is just not something I want to worry about.
However, this third point has improved so much I'm ready to handwave it away if the former two weren't a thing.
Lastly, not an issue with React Native itself, but JetBrains absolutely has the intention to bite into iOS' territory with Kotlin Native... and assuming they can pull off a half-decent adaptation of Apple's APIs I'm betting they will be the ones to finally take the x-plat cake, which makes it hard for me to believe investing time and code into RN solutions is a better proposition than native.
Hope that was useful in some way. If I should clarify anything or I have any misconception about RN please let me know.