Xcode 13.2b2 - Swift build system integration fails to recognise availability checks

I'm unsure if this is specifically an Xcode bug or a bug with the Swift build system, however the beta version of Xcode 13.2 states in the release notes:

  • The build system and Swift compiler have a new mode that better utilizes available cores, resulting in faster builds for Swift projects. The mode is opt-in, and you can enable globally with the following user default:
defaults write com.apple.dt.XCBuild EnableSwiftBuildSystemIntegration 1

Please report any issues with the new build system mode through Feedback Assistant. (84467780)

Of course I wanted to try this out - unfortunately, it looks like enabling this causes Xcode to not recognise if #available checks correctly where the version you are checking is higher than the package platform/minimum deployment target of what you are trying to build.

For example, trying to build the CustomDump library with EnableSwiftBuildSystemIntegration turned on results in it failing to compile for iOS, complaining that certain APIs are only available on iOS 14, even though those calls are wrapped in an if #available(iOS 14) check:

CustomDump has a minimum iOS deployment target of iOS 13.

I have a similar problem with the PhoneNumberKit library, where iOS 11 availability checks break in a similar way. This library has a minimum deployment target of iOS 9.

In both cases, the error can be fixed by increasing the platform/deployment target to at least whatever version is failing in the availability check.

Feedback filed: FB9764935


Yup. Same here. FB9764703

1 Like

Thanks for giving the new integration a try. We're tracking this issue already. It probably got fixed in [Sema] Generate TRC for unparsed functions right before type-checking by xymus · Pull Request #39337 · apple/swift · GitHub.
Thanks for the reports, we'll update through Feedback Assistent once we think it should be fixed.

There are two potential workarounds:

  1. Move the #availability checks to a function and call that from the didSet/computed property context.
  2. This is probably not a realistic option but setting the deployment target high enough (SDK version for example) should also work around.

The line that is failing in the screenshot is not in a didSet so it doesn’t look like the problem is just that.

Unfortunately these workarounds aren’t much help when we are dealing with third party code and I wouldn’t expect libraries to ship new versions with a workaround for this bug so I guess we will just have to wait until it’s fixed.

Terms of Service

Privacy Policy

Cookie Policy