React Native with JUCE

I am building a React Native application that needs to interface with JUCE audio code. Does anyone have a solid example if integrating the two together? I have passed JavaScript down through native modules to C++, but am unsure how to link the JUCE libraries from there.

Thanks!

You might want to check out

AKA react-juce.

1 Like

React JUCE would allow writing in a react/js way but still use juce only.

There’s no simple out of the box solution but this might be worth seeing -

2 Likes

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

Good luck

9 Likes

Thanks for your feedback @evancooney !
I was starting a project based on React-Native + Juce, I guess I will avoid it unfortunately and will need to go with 2 native codebases…
I will also point the fact that Djinni has been deprecated so it might add more complexity in the future.
Too bad we cannot use audio processing lib with React Native