JUCE and macOS 11 / ARM

Chris from Audio Damage (he also posts here frequently) has some really interesting things to say about this: https://www.patreon.com/posts/definitely-whole-38639438

I am concerned that the iOS “race to the bottom” pricing model will find its way to macOS, once users figure out they can buy iOS plugins at a steep discount and run them in a desktop DAW. If developers don’t opt out and keep the two platforms separate, it could be devastating for the economics of audio plugin development.

1 Like

If you ordered your DTK you should have received an email titled “Welcome to the Universal App Quick Start Program” which has links to videos and documentation.

I haven’t had time to check them out yet though.


Cheers for linking. Yes, thats basically my fear. Some of the iOS plugins are dirt cheap for what they are! I have my iOS apps set to not work on Big Sur in App Store Connect but I only have a couple of small free ones on there. The influx of cheap apps to the desktop market is a big concern!

jassertfalse just needs “JUCE_NO_INLINE_ASM=1” in the preprocessor macro as it uses an intel asm call.
objc_msgSend_fpret is not needed on ARM, it’s for i386 only. However it is used in JUCE for a mouse wheel call. Commenting out that section solves this for now.


I believe there are some macros you can add to #if around differences – they mention that in the WWDC video


#if __aarch64__ 

does it.

1 Like

Got my DTK. Initial report:

  1. The Projucer that comes with the JUCE 6 download doesn’t run at all. I was able to build an ARM Projucer with the modifications to JUCE listed above.

  2. Projucer ARM works in general but there are two gotchas I’ve come across so far. First is that there is an instacrash when you try to log in. So I just activated the splash screen and moved on. The second is that the resource-to-binary thing is broken. It makes BinaryData.h and .cpp, but there is nothing in them. So, I just copied the appropriate files over from an existing workspace. This worked fine. I’m sure there are tons more hidden gotchas; these are the only two I’ve come across though.

  3. I was able to build an existing product with no changes whatsoever to the product itself. The major caveat here is that we deploy multi-platform, to basically everything JUCE can build for but Android (because yuck), and this product is like 16 minor and 2 major updates deep (Quanta, if you’re curious.) So I wouldn’t expect any platform-specific bugs, and I didn’t find any. There is no ARM build of Logic, so I can’t test the ARM AUv2 workflow, but the standalone worked fine.

So, initial exploration is pretty hopeful. I don’t think much will need to change with JUCE itself, and it is almost workable as-is.


I’ve had my DTK for a few days. I compiled a few non JUCE Apps for ARM no issues.

Formy JUCE App, I haven’t even gotten the dependencies compiled yet. Currently fighting with brew to install autotools.

1 Like

I wonder about Logic Pro X. does it back to using a bridge when running Intel based plug-ins or as Apple documents mentions about plug-ins, I have to run the entire app under Rosetta so the app itself is also translated for sake of plug-ins?

Surprisingly, a rosetta2 converted host can actually load arm64 plugins! I was able to build my plugins just fine after getting rid of SSE2 stuff in some libraries I’m using and the AUs show up in Ableton Live running converted. That is very good news as it means customers will already be able to take advantage of arm-built plugins before their hosts are updated (which probably will take longer).

I’m also seeing the Projucer problems. Still on v5 here. It seems to have issues accessing some files for writing and cannot display any source-code. Like crandrall I’ve just used the intel Projucer to create the needed files.

1 Like

That would indicate that Ableton Live is probably running the plugins in a separate process… You’ll have to check other hosts which run the plugins in the same process


Ok I’ll check with some other hosts and plugin formats.

Oops. I’m sorry I was wrong :(… Was too good to be true. I didn’t realize my builds were already universal :blush:

With a ARM64-only build I get an error trying to load the plugins and/or they do not show up at all. Of course no one is going to make such a build on purpose.


Heh. I was gonna say that what you described was physically impossible. :slight_smile:

Anyhow, yeah. UB and Intel plugs load fine in Rosetta2 Logic and Live here (caveat emptor: I only have Audio Damage plugs on these machines; I don’t use my Macs for music-making.) ARM-only plugs do not load anywhere. We’re in a chicken-and-egg situation currently.

1 Like

Well the one host that can load arm64 plugins of all sorts is the Juce AudioPluginHost… once you succeed at building it on the platform.

I’m in no hurry. I don’t expect any problems from our product line; the only reason I got this thing was so we could deploy UB on day one. So I’ll just wait until @t0m and @ed95 get their shit together. I’m just generally pleased that the entire system is within sight of working. It mostly seems to be just little shit.

Compared to the PPC->Intel switch (or, god forbid, the 32->64 switch( it is much, much easier.

Still I’m not sure I understand.
From a user pov. I need to run Logic Pro X as Rosseta in order to get my Intel plug-ins running?
(which means the host itself even if UB will run not native when supporting Intel)

1 Like

You’re mostly correct. You don’t have any choice right now. There is no Logic ARM currently. (Although I assume that will change before they deploy to retail.) When you double-click the Logic icon, it is an Intel version running in Rosetta2. It can load Intel plugins.

When you get the UB version of Logic, it will only run ARM plugins, unless you specifically order it to run in Rosetta2 (there will be a checkbox in the get info panel), in which case it will only run Intel plugins. This will be the same for any host that does not have a separate process for plugins. So basically any of the major hosts except Bitwig. I expect that Bitwig will be able to run both Intel and ARM plugins.

Assuming this goes about like the PPC->Intel switch did, you’ll get about 6 months worth of very confused customers, then shit will settle out, and after about 3 years of it, you won’t have to build Intel plugins any more.

1 Like

If you ship your stuff as UB the day the first consumer ARM Mac is out, you’ll have very few issues. People will just need to install your updated versions and those will load in all hosts as ARM or intel. I think I’ll put up a banner next to my contact form to make users get the ARM updates before they contact me.

I’m sure intel macs will be around for much longer than 3 years though. This CPU switch once again has the potential to make all big host developers charge extra for an update… This will make an ARM machine more pricey for audio people and slow down adoption in the audio sector.

1 Like

Yeah, of course. As long as you’re UB, the customer shouldn’t know or care what host is doing what, as long as they remain current. That’s the concept, anyhow. Our experiences with the OSX, Intel, and 64-bit switches show that it is not that simple. tl;dr: ain’t our first rodeo, and trust me when I say that the default setting for customers in the next few months will be “confused.” They just want to make dope beats on their new laptop. They could give a fuck about our problems.

Having said that, Intel Macs will be around for a long time, because Apple makes hardware that lasts, in general. But there will be a point not long after they stop shipping Intel Macs (which will take about a year or two) where there are diminishing returns for shipping a UB, and a point not long after that where you can’t even make a UB any more. The way Apple does things now, that point will come sooner than it did after the Intel switch, as they are more actively pruning legacy than they were then.

1 Like