[feature] SDK Version for apple OSes

This is the second year Apple has made a major change to the SDK within the same major release of Xcode. With Xcode 12.0 Apple shipped macOS SDK 10.15 and with Xcode 12.1 they changed it to macOS SDK 11.0. Now it looks the same (probably because iOS 15 came out earlier than macOS 12) Xcode 13.0 comes with macOS SDK 11.0 and it is sure that one of the next minor updates, probably 13.1, will bring us macOS SDK 12.

Changing an SDK is a big deal as it removes APIs, brings new APIs and can give changes in the behavior of your application. So it’s time to have the ability to differentiate Conan packages by SDK version. The same is true for all other Apple operating systems.

I can add an option myself, or it can become an additional setting under OS

my suggestion would be, these additions in the settings.yml

    Macos:
        version: [None, "10.6", "10.7", "10.8", "10.9", "10.10", "10.11", "10.12", "10.13", "10.14", "10.15", "11.0", "12.0"]
        sdk: [None, "macosx"]
        **sdk_version: ANY**    
        subsystem: [None, catalyst]
    iOS:
        version: ["7.0", "7.1", "8.0", "8.1", "8.2", "8.3", "9.0", "9.1", "9.2", "9.3", "10.0", "10.1", "10.2", "10.3", "11.0", "11.1", "11.2", "11.3", "11.4", "12.0", "12.1", "12.2", "12.3", "12.4", "13.0", "13.1", "13.2", "13.3", "13.4",$
        sdk: [None, "iphoneos", "iphonesimulator"]
        **sdk_version: ANY**    
    watchOS:
        version: ["4.0", "4.1", "4.2", "4.3", "5.0", "5.1", "5.2", "5.3", "6.0", "6.1"]
        sdk: [None, "watchos", "watchsimulator"]
        **sdk_version: ANY**    
    tvOS:
        version: ["11.0", "11.1", "11.2", "11.3", "11.4", "12.0", "12.1", "12.2", "12.3", "12.4", "13.0"]
        sdk: [None, "appletvos", "appletvsimulator"]
        **sdk_version: ANY**    

A consumer of such a package must have the same or higher sdk_version, otherwise there will be linker warnings. Within a dependency tree there should be no differences in sdk_version for the same package

[memsharded]

@NoWiseMan could please you confirm the above Changing an SDK is a big deal as it removes APIs, ? Because that means the SDK doesn’t provide backwards compatibility.

@dheater Regarding CFLAGS=-mmacosx-version-min=10.15, that is the OS version, not the SDK one, isn’t it? (I am no Mac user). Conan toolchains will map the os.version setting to this compiler flag. The OS might indeed have backwards (mostly runtime) compatibility, while the SDK (mostly buildtime) might not.

[memsharded]

@dheater The problem with this fine grained subsettings, like something for libc is that they force you into an exact version. Settings do not have ranges of values, every libc will give you a new binary. This might be ok if you want to work with exact libc version all around, but in practice this is not the common thing, but to work with ranges of libc (typical RHEL6 with older libc, modern Debian with modern libc). But the libc version is not a good solution.

As @NoWiseMan is commenting the Apple SDKs seems to be exact matches, as they add new behavior, but can also remove APIs, and completely break. So consumers might want to make sure they all match an exact SDK, always. So I am not sure this can be generalized to the Linux libc one without causing there more pain than the one it tries to solve.