We have two Mac-only desktop apps built with JUCE.
We’ve been working on them for about 10 years now. They were originally Obj-C but we moved them to JUCE a couple years back.
It has always been my understanding that you should ideally build against the earliest macOS SDK that your app supports to be sure to not accidentally use new APIs not supported on the older version or more generally to have the best compatibility with older versions of macOS.
Apple made this harder and harder over the years and with latest versions of Xcode it requires quite some hacks to be able to build against the 10.13 SDK in our case.
So I’m wondering if I should re-consider our approach.
How are others doing this?
Are you building your apps only against the latest SDKs?
Or do you also try to build against older versions?
Will targeting an older SDK even be possible when building fat binaries with native M1 support?
(We’re currently using Rosetta 2 on M1).
You cannot use an older SDK if you want to build a fat arm binary unless you plan to lipo those manually
as you cannot have a per arch base SDK root (even though xcode allows it)
(I had a ticket with Apple regarding this and they told me it was not possible)
So your only luck right now is to use the right deployment target and pray it will do the trick.
If you build against the newest SDK but with a lower deployment target, use of new APIs should trigger a compiler warning (e.g. “xyz is only available on macOS 11.0 or later”) or an error. If you build with warnings as errors, it’s quite difficult to accidentally use a feature that is only available in newer SDKs.
Yes, this should stop you from using stdlib components which aren’t available on the deployment target.
I just tried it out with std::visit and a deployment target of iOS 9.3, and got a hard compile-time error, without even having warnings-as-errors enabled.
