Sharing code with native apps best practices


I’m embarking on a project where I have to develop native mobile user interfaces (iOS and Android) for an existing desktop JUCE application.

The existing JUCE application can conceptually be divided into the UI part and the CoreLib part (mostly Audio and some Networking).

My plan is to extract the CoreLib part from the app and make it a static library, which I can then link into in the native iOS app (written in Swift), Android app (Java) as well as refactor the existing JUCE app to use it.

But before I start, I’d like to find out if there are any tips/tricks/caveats when sharing a JUCE-based library with native apps and what are some best practices for cases like these ?

For example, is it possible to have a static library based on JUCE which can then be used on iOS and Android ?

Any tips on the subject will be highly appreciated.


@adamski did a talk at the summit on this area that should be helpful, you should be able to find the video on youtube.



Although the iOS aspect could be much simplified, I need to update the example at some point!

The YouTube description does not have the Github link (JUCE team can you add this please?):

I’m currently trying out React Native as another approach to share as much UI code as possible across platforms. Although it has added more steps to the build process and bridging, and opened a can of worms in terms of new things to learn…


Thanks for the link, very informative !

So it seems you’re using one Projucer project to generate the iOS and Android project files from it, with #ifdefs in the code to choose the appropriate includes.

This is a solution, although I’m curious for example, how well does this method play with things like CocoaPods on iOS ?

I was thinking of doing it the other way around - have an Xcode project (and workspace) which then includes and links against the static library (which uses JUCE internally).

Are there any pros/cons to this ?


It works fine with CocoaPods as long as you have the correct build location setting (I’ll dig up the relevant thread in a bit).

I prefer not to have to deal with static libraries if possible, this approach works well for me.