Mac SDK: using latest SDK but ensuring backwards compatibility with earlier deployment target

Viewed 5188

As always when Apple updates OS X, the latest XCode 4.4 dumps the older (10.6) SDK and I find myself needing to use the 10.7 SDK (or 10.8 I suppose) and setting my deployment target to 10.6 to maintain compatibility.

I prefer linking to the older SDK because I know that I cannot by mistake introduce calls to APIs that do not yet exist. Something that I found myself doing regularly when I last tried the inverse approach.

What I find myself doing is that I use the code completion feature in XCode to choose the "right" call for a simple class like NSWorkspace, then everything works fine during development, I forget about it and when I release a new version: Kaboum! The whole application explodes on earlier OS X releases at run-time; often in those hard-to-reach places :-)

Or at least this was the situation for me a few years back.

Surely, by now there's a way to either:

  • making sure you don't introduce API calls that are not yet available in your deployment target even if though they are defined in the SDK

  • detecting such calls during build or static analysis time

I'm sure I've missed something, somewhere along the line.. Please enlighten me!

Best regards,

Frank

6 Answers

Since Xcode 9 there is a build setting doing exactly this, turning on the warning -Wunguarded-availability and/or -Wunguarded-availability-new.

The former warns when an API newer than the deployment target is used. The latter only warns when an API introduced newer than macOS 10.13 or iOS 11 is used in a similar manner.

For an existing project, the former is off by default, and the latter is on by default.

This setting is called “unguarded availability” within Xcode’s build settings pane, and you can choose one of Yes, Yes for all versions, or No from the GUI.

For more details, see the WWDC17 session 411, “What's New in LLVM”, https://developer.apple.com/videos/play/wwdc2017/411/ .

Related