Swift 2.0: Availability Checking

In this short tutorial, I’d like to focus on Swift’s brand new syntax for availability checking. If you’ve done any amount of iOS or OS X development, then I’m sure you know how tedious it can be to check if a particular API is available on the device your application is running on. In Swift 2, this has become much less of a pain for developers.

The Problem

Picture the following scenario. You’re developing an iOS application that targets iOS 7 and up. During last year’s WWDC, Apple introduced a new API for notification registration.

registerUserNotificationSettings(_:)

Does that mean that you need to raise your application’s deployment target from iOS 7 to iOS 8? You could do that, but it would leave a significant portion of your application’s user base in the cold, only to comply with Apple’s new policy for local and remote notifications. Your users won’t thank you for that.

The alternative is to only use the new API on devices that run iOS 8 and up. That makes more sense. Right? The implementation would look something like this.

func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
    if UIApplication.instancesRespondToSelector("registerUserNotificationSettings:") {
        let types = UIUserNotificationType.Alert | UIUserNotificationType.Sound | UIUserNotificationType.Badge
        let settings = UIUserNotificationSettings(forTypes: types, categories: nil)
        application.registerUserNotificationSettings(settings)
    }
    
    return true
}

This is a viable option, but it isn’t witout risk. In this tutorial, I won’t go into the details of what those risks involve, but I do want to emphasize that most developers think it’s fine to use the above approach. The following example shows a variation of this approach, this time using Objective-C.

if ([UIUserNotificationSettings class]) {
    [application registerUserNotificationSettings:[UIUserNotificationSettings settingsForTypes:(UIUserNotificationTypeAlert | UIUserNotificationTypeSound | UIUserNotificationTypeBadge) categories:nil]];
}

While both approaches will work in most situations, there are situations in which you’ll run into problems. Some APIs, for example, start their lives as private APIs and are made public at a later stage. In that scenario, you may end up hitting private APIs on devices running an operating system in which those APIs aren’t public yet. And I’m sure you know what that means.

The Solution

Thanks to the work of the Swift team, the solution to our problem is simple and straightforward in Swift 2. Take a look at the following example. Note that the deployment target of the project is set to iOS 7, using Swift 2 and Xcode 7.

In the example, we are using APIs that were introduced in iOS 8. Because the compiler knows that the deployment target of the project is set to iOS 7, it throws an error, telling us that the APIs we want to use are only available in iOS 8 and up. It knows this by inspecting the SDK for availability information. If you press Command and click the registerUserNotificationSettings(_:) method, you should see something like this.

@available(iOS 8.0, *)
func registerUserNotificationSettings(notificationSettings: UIUserNotificationSettings)

Fortunately, Xcode gives us a solution to resolve the issue. It suggests to use a version check to avoid that the APIs exclusive to iOS 8 and up are called if our users run the application on an older version of iOS.

Note that this feature was introduced in Swift 2. The compiler won’t throw an error if you’re using Swift 1.2. The addition of the version check also makes the example easier to understand. Take a look at the updated example below in which we follow the advice Xcode has givesn us.

func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
    if #available(iOS 8.0, *) {
        let types = UIUserNotificationType([UIUserNotificationType.Alert, UIUserNotificationType.Sound, UIUserNotificationType.Badge])
        let settings = UIUserNotificationSettings(forTypes: types, categories: nil)
        application.registerUserNotificationSettings(settings)
    }
    
    return true
}

The syntax is clear and understandable. Using the availability syntax, we check if the application is running on a device with iOS 8 and up. If it isn’t, the if clause is skipped, otherwise the application calls the new API for notification registration.

Syntax

The syntax is straightforward. We start the availability condition with #available and wrap the condition in parentheses. We can add as many platforms as necessary, separating the list of platforms with commas.

if #available(iOS 8.0, OSX 10.10, watchOS 2, *) {
    ...
}

Note that we end the list of platforms with an asterisk. This asterisk is required and indicates that the if clause is executed on the minimum deployment target for any platform that aren’t included in the list of platforms.

As we saw earlier, we can use the @available attribute to add availability information to functions, methods, and classes. In the following example, we tell the compiler that the useFancyNewAPI should only be called on devices running iOS 9 and up.

@available(iOS 9.0, *)
func useFancyNewAPI() {
    ...
}

Conclusion

Keep in mind that the availability syntax is not an alternative for the two examples I showed you at the start of this tutorial. These examples are flawed and should only be used if you’re using Objective-C or an earlier version of Swift.

The availabilty syntax is yet another reason for migrating your Swift projects to Swift 2. It gets rid of error-prone solutions for checking API availability. The world looks a little bit friendlier with Swift 2. Doens’t it?