After over a year working on project that runs React Native on top of “headless” JUCE, I’d strongly advise you to spend some serious time analyzing why you’re interested in the React Native + JUCE architecture. I can’t go into specifics because it’s a commercial product, but we spent about as much time on features as we did making sure RN + iOS + Android + JUCE all played nice. If we could do all over again, we’d probably do it all in JUCE. The reasons being:
you’re fundamentally fighting two of JUCE’s greatest assets: one language / context (C++) and it’s already truly cross platform.
Passing data between JS → OjbC → C++ AND JS → Android → C++ gets incredibly tedious. We went with a redux style, unidirectional data flow, which helped, but adding a new function means you’re writing multiple helpers/transforms in multiple languages, even if only one of them is doing the heavy lifting. We tried using GitHub - sulewicz/djinni-react-native: A tool for generating C++ to React Native JS bindings and more. to help with this, but we were constantly fighting against it
React Native is awesome, and it’s matured enough to be fairly close to “write once, run anywhere”. But while a features might “work” on both iOS and Android, it might perform drastically different. And 3rd party plugins further complicate things. For example, let’s say a JS slider doesn’t behave the same on iOS vs Android. so you need to use two different slider JS components (or write your own), now you’re writing 6x as much code as if you’d just built it in JUCE
getting your app to build on both platforms is a nightmare. Tom Duncalf has an old but good POC you can borrow some ideas from for the iOS side of things: GitHub - tomduncalf/juce-rn-example . But for Android, STRAP IN ! And then keeping them all in sync…
React / RN saved us a ton of time (especially because we already knew React), and not having to
recompile just to update the UI is obviously incredible, but JUCE’s component library is actually very mature and shouldn’t be thought as an “afterthought” to their media framework (which we incorrectly assumed it was)
TLTR; the time spent building the UI in RN was offset by integrating it with JUCE.
So if your app will be leveraging significant parts of JUCE, just do it all in JUCE. If you’re just playing a some audio files or doing some kind of background media processing, then RN + JUCE is pretty cool (once you get it all boostrapped)
ps looks like @ncthom is doing some cool things with GitHub - nick-thompson/react-juce: Write cross-platform native apps with React.js and JUCE