[Pitch] Extensible availability checking

Evolution Pitches
6

I've posted before about the need for some sort of compile-time check on the availability of particular SDKs in the developer toolchain. See this thread for details… but in short, I want to be able to do something like this:

if #available(macOS 11, *) {
    // This is only available in the macOS 11 WidgetKit SDK;
    WidgetCenter.shared.reloadAllTimelines()
}

However, if I'm using a developer environment that doesn't have the macOS 11 SDK, this fails to compile, because the compiler doesn't even know what WidgetCenter is. (This could happen during an Xcode beta period, for example, when some team members might be using a beta SDK, and others are not.)

If I'm reading this pitch correctly, this use case would be addressed something like this:

if #available(WidgetKit 11, *) {
    // This is only available in the macOS 11 WidgetKit SDK
    WidgetCenter.shared.reloadAllTimelines()
}

If the WidgetKit SDK in the build environment wasn't version 11, then the compiler would just skip over that code entirely, ignoring the unrecognized symbols. Is that correct? I'm sure we can't make any promises about whether Apple would adopt such availability features in their SDK, but does this pitch provide a system that system SDKs (like Apple's) could adopt it? If so, I'm extremely excited about this pitch.

In the case of an Apple framework like WidgetKit, the version number might be tricky. For example, a developer might be tempted to write if #available(WidgetKit 11, *).

But the same SDKs became available on both macOS 11 and iOS 14. If we try to use the OS version number in the library, it's unclear whether it should be WidgetKit 11 or WidgetKit 14. Or if #available(WidgetKit, macOS 11, iOS 14). That all seems a mess. So it seems like system frameworks would need to be able to declare their own versioning, independent of that of the system framework. It looks to me like this pitch would support that kind of versioning. Am I reading that right?

2 Likes