# Sharing code with native apps best practices **URL:** \ **Category:** General JUCE discussion\ **Created:** [May 9, 2016, 10:27pm UTC](https://forum.juce.com/t/sharing-code-with-native-apps-best-practices/17642 "2016-05-09T22:27:26Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![bcn-flor](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/bcn-flor/32/796_2.png) [@bcn-flor](https://forum.juce.com/u/bcn-flor)\ **Post date:** [May 9, 2016, 10:27pm UTC](https://forum.juce.com/t/sharing-code-with-native-apps-best-practices/17642/1 "2016-05-09T22:27:27Z")
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. ---
**Author:** ![martinrobinson-2](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/martinrobinson-2/32/630_2.png) [@martinrobinson-2](https://forum.juce.com/u/martinrobinson-2)\ **Post date:** [May 10, 2016, 9:33am UTC](https://forum.juce.com/t/sharing-code-with-native-apps-best-practices/17642/2 "2016-05-10T09:33:54Z")
@adamski did a talk at the summit on this area that should be helpful, you should be able to find the video on youtube. ---
**Author:** ![willrice](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/willrice/32/55_2.png) [@willrice](https://forum.juce.com/u/willrice)\ **Post date:** [May 10, 2016, 9:41am UTC](https://forum.juce.com/t/sharing-code-with-native-apps-best-practices/17642/3 "2016-05-10T09:41:09Z")
---
**Author:** ![adamwilson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/adamwilson/32/1387_2.png) [@adamwilson](https://forum.juce.com/u/adamwilson)\ **Post date:** [May 10, 2016, 1:30pm UTC](https://forum.juce.com/t/sharing-code-with-native-apps-best-practices/17642/4 "2016-05-10T13:30:25Z")
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?): [https://github.com/adamski/juce-native-navigation](https://github.com/adamski/juce-native-navigation) 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… ---
**Author:** ![bcn-flor](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/bcn-flor/32/796_2.png) [@bcn-flor](https://forum.juce.com/u/bcn-flor)\ **Post date:** [May 10, 2016, 1:53pm UTC](https://forum.juce.com/t/sharing-code-with-native-apps-best-practices/17642/5 "2016-05-10T13:53:38Z")
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 ? ---
**Author:** ![adamwilson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/adamwilson/32/1387_2.png) [@adamwilson](https://forum.juce.com/u/adamwilson)\ **Post date:** [May 12, 2016, 7:50am UTC](https://forum.juce.com/t/sharing-code-with-native-apps-best-practices/17642/6 "2016-05-12T07:50:45Z")
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. ---
**Author:** ![compuswerve](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/compuswerve/32/3007_2.png) [@compuswerve](https://forum.juce.com/u/compuswerve)\ **Post date:** [October 5, 2018, 12:29pm UTC](https://forum.juce.com/t/sharing-code-with-native-apps-best-practices/17642/7 "2018-10-05T12:29:58Z")
In this forum, user john\_henry just informed of another tool called Djinni in a similar discussion: “A tool for generating cross-language type declarations and interface bindings.” > [@Example project from my talk "Mobile Application Development with JUCE and Native API’s"](https://forum.juce.com/t/example-project-from-my-talk-mobile-application-development-with-juce-and-native-api-s/16010/4): > > Yes, I think this is still a valid approach for a native look&feel of your app. Also take a look at djinni by dropbox, which will make communication between C++ and Swift / Jave much easier: It includes bridges for std::string, std::vector and others and will enable you to have 2-way communication including JUCE style listeners. Only downside is you have to define the interface in their own format which gets transferred into glue code for C++, pure Objective-C and Java