Negating Objective-C's @available keyword

Question

I would like to run a piece of code only if the iOS version of the current device is below a specific version, as specified here. The code examples given by Apple look like this:

if (@available(iOS 10.0, *)) {
  // iOS 10.0 and above
} else {
  // below 10.0
}

However, there are scenarios where one would like to run code only if the current iOS version is below a specific version. I assumed the following code will work:

if (!@available(iOS 10.0, *)) {
  // below 10.0
}

However it seems that this doesn't work, and I'm getting the following warning from Xcode:

@available does not guard availability here; use if (@available) instead

Here is the LLVM commit that added the diagnostic I'm seeing.

There are two possible fallbacks to that issue:

1. Use the if-else variant without adding any code to the if block (not very elegant).
2. Continue to use old approaches such as -[NSProcessInfo isOperatingSystemAtLeastVersion:].

Is there another intended way to use @available that I'm missing?

Viaduct

I've read the LLVM article and it states that you can not use @available with any other condition or instruction in an if. So basically the only way I can think of is having an empty if body but do the action within the else block. This seems as the only possible way to me. – Bothersome

"However it seems that this doesn't work, and I'm getting the following warning from Xcode:" Just because there's a warning doesn't mean it doesn't work. The warning says it doesn't guard availability, but you are just using it as a version check, not to guard availability. – Tinctorial

Answer 1

The idea of @available is that you want to use API that is only available on certain systems. For other systems, the functionality is either missing in your app or you offer alternative functionality. The correct way to use it for cases where you don't need any code beyond a certain OS version, only below, is

if (@available(iOS 10.0, *)) {
    // Happens automatically on on iOS 10 and beyond
} else {
    someOtherCode();
}

The reason for that is that the compiler sometimes has to perform some extra magic to code guarded by @available and therefore it needs to clearly recognize when this is the case. So in fact it explicitly searches for

if (@available(...)) {

with only variations in spaces and line breaks allowed. Yes, you may ague that a single not (!) is really anything but complicated yet where would you then draw the line? What about:

if ((todayIsTuesday() && @available(iOS 9.0, *)) 
    || (self.theWeatherIsNice && !@available(iOS 11.0, *)) {

Thus only a simple statements are allowed that only force the compiler to divide code into two sections and where always only one section will run for sure: One for the listed OSes and one for the rest. Of course, "the rest" can then be subdivided again, else if is allowed. Only the else section can be auto-generated if missing, so when you write this:

if (@available(...)) {
    someCode();
} // There is no else

The compiler is also happy as that is the same as

if (@available(...)) {
     someCode();
} else {
    // Nothing to do here
}

Momentarily

Accepting for the elaborated answer. I agree with your reasoning, although I think that this specific case for negation deserves special handling. – Viaduct

@Viaduct Maybe you should file an enhancement request to clang but not on Apple's portal but directly on the LLVM portal. Either they will implement it or they will provide a good reason why they don't want or technically cannot implement it that way. The LLVM devs seems very reactive, also filed issues there before and they all got fixed. – Momentarily

Answer 2

You can define your own custom macros that you can use throughout your application. Example:-

#define isIOS11() ([[UIDevice currentDevice].systemVersion doubleValue]>= 11.0 && [[UIDevice currentDevice].systemVersion doubleValue] < 12.0)

or

#define SinceIOS9_2 ([[UIDevice currentDevice].systemVersion doubleValue]>= 4.2 && [[UIDevice currentDevice].systemVersion doubleValue] < 9.2)

Use it like below:-

if (isIOS11()) {
    // Do something for iOS 11 
} else {
    // Do something iOS Versions below 11.0
}

Please let me know if this works for you.

Ketti

This is neat. I think I'm gonna try that one someday. Thanks! – Fingerboard

This will not suppress the new "Unguarded Availability" warnings in Xcode 9. – Viaduct

Answer 3

if (@available ...) {
   ...
} else {
   ...
}

is the only form that is allowed. It has to be like that, because different rules apply in the if-part and the else-part. In the if part you can call methods available in one SDK, in the else part it's methods from another SDK. The same call can be legal in one branch and illegal in another, or deprecated in one branch and not in another.

Bradleigh