Question to devs: if you were developing solely for Apple app markets would you still use JUCE?


Just out of curiosity - how many here - if they were developing audio apps for only the Apple ecosystem - and eschewing other platforms - how many would still choose to use JUCE ?

And if currently writing for Apple alone - How many here are considering or would consider switching to writing primarily in Swift, using something like AudioKit with just the occasional C++ or ObjC for low level audio where needed?

How long before Swift becomes a serious contender for real-time audio programming - requiring no bits of C++/C here and there?

This becomes a little more salient now that i’ve come across many reports of Android hardware vendors eschewing the tablet marketplace almost altogether… and clearly Microsoft has no ARM based tablet out there at all…


As someone who has written Apple-only apps with JUCE, the answer is an emphatic yes, for a few reasons.

The biggest is that IMO JUCE’s APIs are simply better than all native APIs, even Apple’s (sometimes especially Apple’s). They “just work”, and are very well documented with full source access and a direct line to the developer (Jules for clarification if needed. This API superiority is true for all aspects of JUCE - audio setup, GUI, video playback, etc. especially when it comes to writing audio plugins.

Additionally, using JUCE’s widgets allows you to sidestep using the extremely long-in-the-tooth AppKit/UIKit + the travesty that is modern iterations of interface builder, and instead use a super simple and reliable MVC listener system. Much of JUCE’s design is very KISS oriented, and while it may involve a bit more typing in the short term (i.e. implementing Listener methods) it makes the architecture so much easier to follow later.

I haven’t used Swift much, but I know it’s a nice language and is useful for app developers. I don’t know much about its implied vs. guaranteed performance characteristics so I can’t comment on its usefulness for real-time applications, but I think for most low-level systems and multimedia framework developers Objective-C/C++ continues to reign and will for a long time. From an engineering standpoint, the reasoning is because of 1. The amount of legacy code which would need to be converted and thoroughly debugged and 2. the fact that Swift has no native C++ interop akin to Objective-C++'s “how is this even working” level of homogenous inter-language flow. In Swift, you have to write C or Objective-C wrappers for all C++ code. Not fun when you’re trying to bring in an external library!


thanks for that detailed and helpful response.


I spent over a year working on a very complex audio app thinking I would just target Apple platforms. I am a Swift fan and have released three comparatively simple iOS apps. I have been developing in C++ for as long as there has been C++ and must confess I am not an Objective-C fan. I agree with everything @jonathonracz stated except that JUCE is MVC. The “Controller” part is really up to you to implement if needed. If you use the ProJucer button event callbacks, etc. will be placed in the view which I have been fine with.
I initially decided to use Swift and I was able to get a performant app by just implementing the audio engine callbacks in C. Don’t make the mistake I made. If your app is worth developing why would you want to exclude the huge Windows user base. I have spent the last several months porting my existing functionality over to JUCE and I believe it was a wise decision. If you develop your app using modern C++ there is very little you will miss from Swift. When I started out with Swift I wrote all my code in C style using parenthesis and semicolons but over time migrated to the Apple recommended style. That was a major mistake because it made porting to C++ much more painful.
Changing what the UI looks like in Cocoa is much more difficult than you would think, trying to make an app that looks like GarageBand or iMovie and you will find yourself down in the bowels of the frameworks and writing many custom components. With JUCE I have been able to share way more UI code between iOS and macOS than I was able to with Swift.
There has been very little in JUCE that has not worked exactly the way I expected it to work and the more you use it, the less you even need the class reference to search for method names. Sorry to rant, if you have any specific questions this is one area where I feel I have a lot of experience because I went so far with my app using Swift/Cocoa before moving to JUCE.


To be honest, i think your question is a complex one. Firstly, I would never find myself in such a circumstance where I wanted to permanently exclude Windows users. Having said that, I can see a circumstance where I might like to stop using JUCE. And it is not the circumstance that you speak of. Instead, I would probably stop using JUCE if I was to find that my company was making more than 10 million per year in revenue and I could afford to have my own team dedicated to building our own code library.

It’s not that there is a problem with JUCE. It’s just that in the ideal situation, I would have the library written in a way that fits the company’s culture, philosophy and goals. Currently, I find JUCE to be very useful, but there are frequently times when the standard classes were designed in a very different way from how I want to use them. I can certainly inherit those JUCE classes and absorb their most useful methods, but this can get a bit cumbersome and messy at times.