Until now I have building my plugins in “Universal Binary” (x86 and ARM-64) on an Intel-Mac machine under Xcode 12.5.1 running on Big Sur (OS 11).
AFAIK, the plugins have been working on both M1+ and Intel Macs but I have not been able to directly confirm or test on an M1 because I did not have an M1 machine (I relied on beta testers who had M1 machines).
I have finally purchased an M1 - but now I have a new problem. The M1 came loaded with OS Sonoma and when I tried to load Xcode 12.5.1 on it it refused saying that 12.5.1 was too old and I needed a newer version of Xcode. Conversely, I cannot load Xcode 15 on my Intel Mac running Big Sur because XC15 is too new!
Just to check, I tried opening some of my known-good iPlug2 projects on the new M1 under Xcode 15 and it failed, complaining that it couldn’t open the AAX and other library files. I checked the paths and all are correct so maybe it’s looking for ARM versions of these library files? I’ve been building ARM-64 with them on my Intel Mac so I thought the libraries were already ARM-compatible.
So now I have 2 questions:
Is there any version of Xcode that will run on both Big Sur and Sonoma so that I can use it on both machines to keep everything consistent?
or,
Do I need to have two different sets of iPlug2 setups and libraries - one for the x86/Intel Mac machine and the other for the ARM Mac machine?
This seems a total mess. How are you guys handling these two different Mac OSs?
I’m not sure, but you really shouldn’t need to run the same version on different machines. you should be able to target both architectures on your new M1 machine.
If you want to generate universal binaries on your M1 mac, you need to make sure that all your 3rd party libraries are universal too. This is simple if the libraries you’re using support CMake. You need only pass the following option when generating your projects:
-DCMAKE_OSX_ARCHITECTURES="arm64;x86_64"
I’m new to iPlug, but I assume you can the same your iPlug projects if you generate them with CMake. I haven’t tried it myself yet, I’m still finding my feet
The problem is not in building the code - we can build “universal binary” on either an x86 or an ARM machine - the problem is debugging the code when something isn’t working right.
In order to debug on an M1 machine we have to run Xcode in debug mode with a debug build on that machine - and in my case with OS Sonoma, it has to be Xcode v15.
To debug on an x86/Intel Mac we have to run Xcode in debug mode on that machine - which in my case only supports Xcode v12.5
Those two Xcode versions are not compatible/interchangeable.
So, since I can’t run the exact same universal binary debug build on BOTH machines how do I know if the “universal binary” produced on either machine is good on the other machine?
It seems to me the “Universal Binary” claim is a farce. What Apple actually has now are two different OS systems (“old” x86 and “new” ARM) with 2 different sets of code, build settings and debugging requirements. Apple has increased the support and development effort for software 2-fold. The “Universal Binary” band-aide temporarily bridges the gap to ARM - but it does so with issues as explained here.
If I’m wrong about this and over-complicating the situation please advise how YOU are building and testing your plugins on Mac. I would really like to know what everyone else is doing!
I really haven’t seen a two fold increase in development efforts at all. For the most part the code is the exact same. As far as I am aware, plugin APIs don’t provide different code for each arch and I’ve never once had to use any kind of arm/x64 ifdefs.
In my experience I’ve never had a bug report that was exclusive to Intel or Silicone chips, which is just as well as I no longer have an Intel machine. When a bug report comes in I debug using whatever tools I have at my disposal on my M1 mac and publish an update. If it passes on my M1 mac it’s always worked fine on user’s Intel machines. Maybe I’m just lucky, but that’s my experience.
In summary, I’m building exclusively on an M1 Mac. I’m debugging exclusively on an M1 mac, and I’m releasing universal binaries. I’ve never had a bug report that targeted one particular architecture.
Unfortunately I have. For example, I have an issue right now where what works in Logic Pro on OS Mojave, Big Sur and Monterey (all on x86) is not working in Logic Pro on OS Sonoma (M1/ARM).
As I said above, the only way to debug this is by using the version of Xcode that runs on that machine.
I think you’ve just been lucky. I made that same assumption but found out it’s not always true (current case). Many users trying plugin demos won’t bother tell you if something’s not working right - they just delete it and move along. In order to be thorough, IMO, we have to test on both architectures natively.
In this case I guess I’ve just been extremely lucky But there is always time for me to get caught out. It’s not a great situation then you find yourself in. I’m not sure what the solution is.
I didn’t think this situation was unique to me - it applies to everyone building for Mac desktops and laptops these days due to the 2 different architectures - which is why I asked here. “Universal binary” may be right most of the time but it is not necessarily identically translated code.
Perhaps if I move all of my iPlug2 projects to a newer ARM/M1 machine and then build universal binary it might be more reliable than building universal binary on my older x86 machine. In other words, build backwards to x86 from M1 rather than forwards to ARM from x86. Maybe that would make a difference - or maybe I would then have problems on x86 machines, IDK. Debugging on both is still an issue either way.
But there is always time for me to get caught out. It’s not a great situation then you find yourself in. I’m not sure what the solution is.