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
No there is not. Yes, you should open a radar (bugreport.apple.com) against it. If you like, you can dupe mine: rdar://11985733
Yes, the only viable solution, despite Apple’s recommendation, is to copy the old SDKs and link against them.
I spent quite some time talking with the Xcode team about exactly this issue at WWDC 2012. They agreed that it’s broken. There is not currently a plan to fix it. Escalating radar’s is how we influence Apple on these things.