macOS SDK version for M1

[Markus Krause]

What is the minimum macOS SDK version to build binaries for the M1 chip in XCode? I want to be as compatible as possible with older OSX versions

[FigBug]

macOS 10.9 (Mavericks 2013) is the oldest Deployment Target supported by Xcode 12.2

[Markus Krause]

Thanks

[syntonica]

I wouldn't worry about dropping support for anything earlier than 10.9 Mavericks. It was the last great 32-bit OS. I'd say High Sierra will be the last great 32/64-bit OS. Anything after that is Apple spyware that Microsoft only dreams of!

[FigBug]

I just did some testing, my DAW works back to 10.9, however fat binary plugins are only loading on 10.10 and newer

[adammonroe]

It's not really possible to compile against the 10.9 SDK for Arm64. There are Arm macros and dependencies that don't exist in the 10.9 SDK, because Arm64 didn't exist as a build option in OSX 10.9 (this is different then the deployment target, I'm talking about building against the actual SDK). When did Apple introduce the Arm Macros? They aren't even in the older 10.15 SDK I have, so it seems to be a completely new thing in the SDK that came with the XCode12 update. So technically, you can only make an ARM build for 10.15 or above. However, I'm going through and copying all the Arm stuff from the 10.15 SDK into the 10.9 SDK to see if I can hack it to work, because it would be nice to have a Universal Build for 10.9-10.16, as opposed to having to maintain separate versions for Big Sur and later OS Xs. This might be possible, as it seems like most of the difference is type defines and such, but it will take some finessing. I'll let you know how it goes.

[syntonica]

Unfortunately, you have two different target OSes, so you would have two targets to run separately. You can use the lipo tool to combine your binaries into a single executable file.

https://developer.apple.com/documentati ... cos_binary

I only glanced at this, but I hope it's helpful.

[FigBug]

Why do you want to build against the 10.9 SDK? What's wrong with just building against 11 SDK and setting deployment target to 10.9? That's what I'm doing and my builds seem to be working back to 10.10.

10.9 isn't loading, but I think that's a signing / notarizing issue, not something to do with the SDK.

[adammonroe]

Why do you want to build against the 10.9 SDK? What's wrong with just building against 11 SDK and setting deployment target to 10.9? That's what I'm doing and my builds seem to be working back to 10.10.

10.9 isn't loading, but I think that's a signing / notarizing issue, not something to do with the SDK.

Because each version of OS X has it's own individual frameworks and libraries. When you build against a newer SDK you could be rolling API and function calls that don't even exist on older OS X into your code, causing crashes. Likewise, if you build against an older SDK, you might have code that's depreciated on newer OS X. Changing the deployment target doesn't fix any of this. All changing the deployment target does is allow your code to run on older version of OS X, but unfortunately, it doesn't guarantee that anything will actually work.

Best example is when Apple shifted from Carbon to Cocoa. If you build something with Cocoa GUI Framework and try to run it on OS X 10.7 or earlier it won't work because from the perspective of the older OS, Cocoa doesn't exist.

Anyway, hacking the 10.9 SDK doesn't seem possible as you eventually run into a bunch of framework dependencies. Once you start changing those, you are pretty much just compiling against the newer SDK.

[FigBug]

Best example is when Apple shifted from Carbon to Cocoa. If you build something with Cocoa GUI Framework and try to run it on OS X 10.7 or earlier it won't work because from the perspective of the older OS, Cocoa doesn't exist.

This isn't correct. Cocoa has been a part of OS X since version 10.0.

You can use `-Wpartial-availability` to get a warning anytime you use a function that doesn't exist on your deployment target.

[adammonroe]

Best example is when Apple shifted from Carbon to Cocoa. If you build something with Cocoa GUI Framework and try to run it on OS X 10.7 or earlier it won't work because from the perspective of the older OS, Cocoa doesn't exist.

This isn't correct. Cocoa has been a part of OS X since version 10.0.

You can use `-Wpartial-availability` to get a warning anytime you use a function that doesn't exist on your deployment target.

Yes, but the frameworks have changed significantly. Build a Cocoa App against the 10.9 sdk and see if it works on 10.7. In my experience, it doesn't. Even the old VST 2.4 sdk was written using carbon, so if you wanted to use it or build 64-bit plugins, you had to rewrite your GUI in Cocoa. The point is that Apple is changing and replacing their frameworks constantly. You need to test your builds across whatever versions of OS X you are targeting, because sometimes they don't depreciate frameworks, they just change how functions behave. I remember the way modal event loops worked changing on El Capitan. If they didn't change, everyone wouldn't be getting random bugs with each new OS X release, because our code doesn't change, Apple's does. And sometimes they through in a programming language change, a slow OpenGL depreciation, or a completely new chipset in for good measure.

[Zaphod (giancarlo)]

The 10.9 target comes handy all the times you want an universal binary (and you need backward compatibility for Intel code). The silicon side just discards the target and it uses 11.
Anyway it is not so necessary, you could just "lipo" the binaries.
For example we have arm code compiled in xcode 12 and Intel code compiled in xcode 3 and xcode 10, and we could merge those ones as we want using the command line
It's the same for frameworks

[FigBug]

For example we have arm code compiled in xcode 12 and Intel code compiled in xcode 3 and xcode 10

Xcode 3??? That's from 2007. Is there really still a market for PPC plugins? Is it really worth limiting yourself to an ancient version of C++ / Objective-C just to support these machines? Or do you have different branches of your codebase for each Xcode version?

I'm happy building everything with Xcode 12.2 and the latest SDK. I can support back to 10.10 (and hopefully 10.9 if I can figure out the signing issue). Do people who don't update their OS for 6 years even buy new software?

[Markus Krause]

So far I have been building with XCode 10 with the 10.11 SDK towards 10.7 as deployment target. It worked fine, also with Notarisation.
I dropped PPC aready 5 years ago and did not receive complains from the customers. They were fine to use just an older version of the plugin till they bought a new computer.
Last year i dropped 32 bit support for the plugins and did not receive complains from the customers. They were fine to use just an older version of the plugin till they bought a new computer.
So it is safe to stick with 64 bit Intel and ARM for the future.
I will now switch to XCode 12. I hope that eveything still compiles for the ARM CPUs. Most likely it should not be a major problem, since I already use Cocoa as a GUI framework for the VST 2.4 plugins.
One bummer we could experience in the near future is Apple's OpenGL deprecation. Nearly all VST3 plugins (as well as the oney which have been wrapped to AU) use it. Steinberg's VST 3.7 SDK still uses it. Juce ueses it.

[lkjb]

Nearly all VST3 plugins (as well as the oney which have been wrapped to AU) use it. Steinberg's VST 3.7 SDK still uses it. Juce ueses it.

Do you have any source for this? I'm almost certain JUCE uses Core Graphics on macOS and OpenGL is only an option that - as far as I know - very few plugins use.
Searching for "gl.h" in the VST3 3.7 SDK only gives two results in "vstgui4\vstgui\tests\uidescription vst3\source\openglviewtest.cpp". But this is a VST GUI example which has nothing to do with the SDK as such.