Checking compatibility with older OS X

I have a large macOS project that is getting close to release, and now the work of compatibility testing on older operating systems begins.


We would like to support OS X 10.9 through macOS 10.13. Right away, all of the apps crash on 10.9 because—somewhere—there's an inadvertent reference to a symbol or function call that was added in a later OS.


So....


It would seem like there would a be a tool in Xcode that would help identify symbols/classes/methods/functions that might not be available in the deplyment OS. But I can't seem to find anyway of finding said symbols.


My next thought was to simply change the Base SDK to 10.9, compile the projects, and see what errors I got. I could then verify that every "undefined" reference was property protected by code that used an alternate method on an older OS. But it now seems that Xcode 9 only ships with macOS 10.13 SDK and there no longer a place to downloading earlier SDKs. (I swear the "components" section in the settings used to have an SDK tab where you could get them.)


I can't be the first developer to run into this problem.


Any suggestion?

Accepted Reply

Found it!


Thanks Quinn, that set me on the right path.


So Xcode 9 includes a new CLANG_WARN_UNGUARDED_AVAILABILITY build setting. If set to YES it causes the -Wunguarded-availability-new switch to be passed to the compiler.


However, this setting only checks for the use of post-10.13 APIs. If your deployment is set to 10.9 and you use a 10.11 feature, you still don't get a warning. This is the default setting, and is why I wasn't gettting any warnings.


To get a warning about the use of any post-deployment API feature you have to set CLANG_WARN_UNGUARDED_AVAILABILITY=YES_AGGRESSIVE (or "Yes (All Versions)" as it appears in the Xcode build settings). That setting invokes the more thorough -Wunguarded-availability compiler switch.


Now you'll get a warning about any (unguarded) API usage.


I now have about a thousand warnings to go reivew, but I'll sleep better at night.

Replies

What language are you working in? Swift? Objective-C? Both?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

My bad: this is all Objective-C


I did find CLANG_WARN_UNGUARDED_AVAILABILITY. It is turned on in all targets, but doesn't seem to have any effect. I suspect, from the description, that it's a Swift-only warning.


What I'd really like is:

  1. a warning that I've referenced a symbol that isn't available in my deployment OS and
  2. a clang directive to suppress that warning once I've determined that the code takes the appropriate steps to remain backwards compatible with the deployment OS.


Is there such a thing, or is it feature request time?

We recently added Swift-style availability checking to Objective-C. You’ve stumbled across this already (

CLANG_WARN_UNGUARDED_AVAILABILITY
is for C-based languages, not Swift) but you seem to be having problems getting it working. There’s a basic summary of it in the Xcode release notes. I’m not aware of any comprehensive Apple docs on this but if you have specific problems you should feel free to post them here and I’ll take a look.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Found it!


Thanks Quinn, that set me on the right path.


So Xcode 9 includes a new CLANG_WARN_UNGUARDED_AVAILABILITY build setting. If set to YES it causes the -Wunguarded-availability-new switch to be passed to the compiler.


However, this setting only checks for the use of post-10.13 APIs. If your deployment is set to 10.9 and you use a 10.11 feature, you still don't get a warning. This is the default setting, and is why I wasn't gettting any warnings.


To get a warning about the use of any post-deployment API feature you have to set CLANG_WARN_UNGUARDED_AVAILABILITY=YES_AGGRESSIVE (or "Yes (All Versions)" as it appears in the Xcode build settings). That setting invokes the more thorough -Wunguarded-availability compiler switch.


Now you'll get a warning about any (unguarded) API usage.


I now have about a thousand warnings to go reivew, but I'll sleep better at night.