Personally I have found that RN does require some amount of native platform knowledge to be successful. However, the bulk of our app is actually in React Native. The times we've had to bridge into native is mostly around our voice modules or things that, in RN, were not very performant (like poor list performance) or required synchronous updates (like the keyboard problem mentioned in the post). Certain multimedia objects RN doesn't support out of the box but the community has come to the rescue (ie: https://github.com/cornedor/react-native-video-player for video).
In practice, most of it is wrapping "RCT_EXPORT_METHOD" around native code and importing it into JS.
Even if you had to write half the app in native code (which you won't), you're still far ahead of having to write it all in native code on both platforms.
Agreed. Creating bridging modules aren't that complicated. For anyone interested, I've linked a sample of a bridging module from my open-source project, for both IOS and Android. See [0] & [1]
The bridge creates an interface between an embedded webserver to react native.
Things to note:
1. Always dispatch bridging methods to their own threads. On IOS you can do this via. dispatch_async. On Android, you can utilise native threads or some kind of task management library. I like Bolts [2].
2. Always create bridging methods that resolve promises. This makes it easy to utilise async / await paradigm on the JS side.
