Hi all
Someone requested a link to the example project from my talk at the JUCE Summit. So here it is:
https://github.com/adamski/juce-native-navigation
Also contains a PDF with the slides from the talk.
Any contributions to improve the example project welcome!
Thanks for sharing this!
Has anything changed since 2015 that might lessen the need to mix in Native APIs for mobile development?
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
I’m quite curious if Swift Package Manager can help with this now that iOS is supported and it’s fully integrated in Xcode 11.
I’m not sure how Swift Package Manager would help with this, can you clarify what you mean?
BTW there is a much better example of this now online, see https://github.com/adamski/audioengine-demo
I think you’re right actually. It would mostly help with reuse of the Juce + Glue code which would mostly be beneficial if you’re reusing your Juce components in multiple Swift projects. And I see your project is not trying to do this so sorry for the confusion.
Aside from that, good to know that there’s a new example. I’m going to need to do this soon so this will be very helpful!
My original strain of thought was that SPM for C++ would work like Cocoapods worked for Objective C where you could keep your main project a pure swift project. While this still may be true, there will still be a need for glue code because C++ and swift don’t like talking to each other (where objc and swift do).
Nice! So many thanks for the build stuff, that is a black hole of time for devs migrating from other techs.
