On more than one occasion I've seen crashing bugs appear on iOS 3.x due to use of a new call that was introduced in 4.x without proper checking.
Is there a way for XCode to warn about classes, methods and procedures that are only available a later version than the deployment target?
That way I could easily list through all the code and make sure it's properly conditionalized.
Latest Xcode didn't work with other answers. This works for me (only looking for UIKit issues).
The reason is that the newer clang versions have a built-in availability attribute.
To get this to work under XCode 5 you need to also redefine the NS_AVAILABLE and NS_DEPRECATED macros because CFAvailability.h distinguishes between compilers that support the attribute_availability_with_message feature. Copy the following above the "MJGAvailability.h" import in your precompiled header to get this to work with the new Apple LLVM compiler:
If you use XCode7.3 and above, you can set other warning flag:
-Wpartial-availability
, then xcode will show warning for API newer than deployment target versionI've actually released something which helps with testing this sort of thing. It's part of my MJGFoundation set of class called MJGAvailability.h.
The way I've been using it is to apply it in my PCH file like this:
Then it'll warn (with perhaps a strange deprecation warning) about APIs which are being used that are too new for the target you set as the "soft max" as per the
#define __IPHONE_OS_VERSION_SOFT_MAX_REQUIRED
. Also if you don't define__IPHONE_OS_VERSION_SOFT_MAX_REQUIRED
then it defaults to your deployment target.I find it useful because I can then double check which APIs I'm using that are too new for the deployment target that I've set.
it's not integrated into the toolset. one option to test this is to just create a runtime check which would assert (during development while running in newer versions of the os).
then just add that to one of your library's initialization routines.
you could also create a script which would count the number of warnings emitted for a specific translation - if the warning count in question changes then you have updates to make.
This is based on Ben S's answer, but incorporates support for GCC and LLVM-GCC. GCC's
deprecated
attribute doesn't take a message argument like clang's, so passing one produces a compiler error in basically every file.Place the following code at the top of your
ProjectName-Prefix.pch
file to get a warning for every use of an API that may not be available in all your targeted versions:As Ben says, if you're intentionally doing this (perhaps by checking for the selector at runtime), you can hide the warning using this construct:
Regrettably, you can't do this inside a function, at least in
i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1
.