SE-0290 introduces an inverted form of #available
called #unavailable
, which will run some code if an availability check fails.
This is going to be particularly useful in places where you were previously using #available
with an empty true block because you only wanted to run code if a specific operating system was unavailable. So, rather than writing code like this:
if #available(iOS 15, *) { } else {
// Code to make iOS 14 and earlier work correctly
}
We can now write this:
if #unavailable(iOS 15) {
// Code to make iOS 14 and earlier work correctly
}
This problem wasn’t just theoretical – using an empty #available
block was a fairly common workaround, particularly in the transition to the scene-based UIKit APIs in iOS 13.
Apart from their flipped behavior, one key difference between #available
and #unavailable
is the platform wildcard, *
. This is required with #available
to allow for potential future platforms, which meant that writing if #available(iOS 15, *)
would mark some code as being available on iOS versions 15 or later, or all other platforms – macOS, tvOS, watchOS, and any future unknown platforms.
With #unavailable
, this behavior no longer makes sense: would writing if #unavailable(iOS 15, *)
mean “the following code should be run on iOS 14 and earlier,” or should it also include macOS, tvOS, watchOS, Linux, and more, where iOS 15 is also unavailable? To avoid this ambiguity, the platform wildcard is not allowed with #unavailable
: only platforms you specifically list are considered for the test.
SAVE 50% All our books and bundles are half price for Black Friday, so you can take your Swift knowledge further without spending big! Get the Swift Power Pack to build your iOS career faster, get the Swift Platform Pack to builds apps for macOS, watchOS, and beyond, or get the Swift Plus Pack to learn advanced design patterns, testing skills, and more.
Download all Swift 5.6 changes as a playground Link to Swift 5.6 changes
Link copied to your pasteboard.