Modifies the availability macros so that usage of API introduced after the Development Target causes a deprecation warning.

Any such libraries will be weak linked (which is the usual behaviour of the old macros and the availability attributes).

Usage

Change your precompiled header file to import DCAvailability.h instead of Availability.h:

#import <DCAvailability.h>

NOTE: Does not work as simply with modules enabled (see below)

If you handle such calls at runtime, e.g. using respondsToSelector, you can ignore the warnings like this:

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wdeprecated-declarations"
    if([something respondsToSelector:@selector(doSomething)]) {
        [something doSomething];
    }
#pragma clang diagnostic pop

Modules

When modules are enabled, frameworks are added automatically when imported, and the code is only compiled one time no matter how many times you import it. This means that there is no way to redefine the macros that we need. Well, you can, but they are only redefined for use in your code, the module has already been compiled before you redefine the macro. This is actually specifically pointed out as a benefit - modules are not susceptible to local macro redefinition.

You have to turn off modules for DCAvailability to work.

All is not lost however

It's still relatively simple to work around it. It means that the checking is not going to be done automatically every time you build, but it will still give you a scheme to select to do check manually from time to time - it's better than nothing.

How to use DCAvailability with modules enabled

• Duplicate your Debug configuration, call it Availability
• Duplicate your app target, call it Availability, use the same Info.plist file (multiple targets? duplicate them all)
• Create a scheme called Availability (one may have been autocreated when you added the new target) which builds the Availability target(s) using the Availability configuration
• Create a group called Availability
• Add a prefix header (put it in the group to keep things tidy)
• #import <DCAvailability.h> in the pch file
• Edit the configuration to disable modules, use the prefix header, precompile the prefix header
• Add any frameworks that you use to the Availability target(s) (put them in the group to be tidy)

Now, when you want to check that you have not used anything that might not be available at runtime, build the Availability scheme.

Issues with this approach

You cannot use @import. I think this should not be a concern as any #import statements are automatically converted into @import when you do enable modules (all your other configurations).

There can be issues with cocoapods when you have a custom config. E.g. CocoaPods did not set the base configuration of your project because your project already has a custom config set. Ugh. It seems that if you add the custom config and then add other pods with pod install, you might get this message, but it all still works. Trying to add a custom configuration to a project that already had working pods installed caused all manner of problems, preventing it from linking properly. There is likely something that I am missing but I don't understand that part of cocopoads well enough to know what it is trying to do.

Author

David Clark, [email protected]

License

DCAvailability is available under the MIT license. See the LICENSE file for more info.